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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 



Introduction 



The approach being taken to standardization in NGN is as six projects: 

NGNl: Architecture, 

NGN2: QoS, 

NGN3: Sei-vice Platforms, 

NGN4: Network Management, 

NGN5: Lawful Interception, 

NGN6: Security. 

Its aim is to allow much greater scope for competition through innovation in the design of equipment and services. Its 
aim is also to provide adequate standardization to facilitate the operation of services across interconnected networks, 
even networks that use different technologies. The present document presents the initial core set of Service Capabilities 
envisaged to be required to enable service providers to offer services on TIPHON and UMTS networks that may safely 
interwork with existing PSTN and ISDN services while enabling more advanced services to be subsequently developed. 
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Scope 



The present document is an analysis of the mapping of concrete functional architectures as defined in UMTS IMS and 
MSF to the TIPHON release 3.0 call control architecture. 

Whilst developing a generic NGN reference model, reference points and the requirements for protocols and interfaces 
for interconnection are identified. The objective of the present document is to verify implementation oriented 
architectures against the Release 3 architecture, as developed in EP TIPHON TS 101 314 [6]. This will highlight if there 
are incompatibilities between the architectures. This study will use the framework for interconnection reference points 
as defined by ITU-T SG13 in ITU-T Recommendation Y.140 [50]. 

Ideally, the generic reference model defines a reference architecture, which is technology independent. A functional 
architecture for NGN study approaches this subject by considering a decomposed call control reference model and 
collecting functional entities into a simplified logical structure, and referencing possible implementations. 
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Part 1: Overview (Parlay 3)". 

[60] ETSI TR 122 121: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Service aspects; The Virtual Home Environment; Stage 1 
(3GPPTR 22.121)". 

[61] ETSI TS 122 101: "Universal Mobile Telecommunications System (UMTS); Service aspects; 

Service principles (3GPP TS 22.101)". 

[62] ETSI TS 122 233: "Universal Mobile Telecommunications System (UMTS); Transparent 

end-to-end packet-switched streaming service; Stage 1 (3GPP TS 22.233)". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

administrative domain: collection of physical or functional entities under the control of a single administration 
NOTE: See TS 101 314 [6] 
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aggregate bearer: logical association of functional entities in an IP based telephony application and transport network 
which creates one or more concurrent end to end media flows and which is not limited to the duration of a single call 

NOTE: See TS 101 314 [6] 

Aggregate Bearer Admission Control (ABAC) function: functional entity that determines whether or not a flow is to 
be admitted as part of an established aggregate bearer 

NOTE: See TS 101 314 [6] 

Aggregate Bearer Measurement (ABM) function: function that determines the capacity used and remaining in an 
aggregate bearer as a result of measuring the actual media flows after taking into account what flows were requested 

application data: media or signalling information content 

NOTE: See TS 101 314 [6]. 

bearer: association of transmission channels or circuits, and switching, set up to provide a means for transfer of 
information between two or more points in a telecommunication network 

NOTE: It does not include control signalling, see EN 301 276-1 [51]. A information transmission path of defined 
capacity, delay and bit error rate, etc, see TR 121 905 [11]. 

Core Network (CN) and Access Network (AN): The PLMN infrastructure is logically divided into a Core Network 
(CN) and an Access Network (AN) infrastructures, as defined in TS 123 101 [25] and TS 123 1 10 [26]. The CN is 
logically divided into a CS domain, a PS domain and an IM subsystem, as defined in next subclause. The AN is called 
BSS for GSM and RNS for UMTS, as defined in clause "The Access Network". See TS 123 002 [18]. 

Circuit Switched (CS) and Packet Switched (PS) Domains: The CN is constituted of a Circuit Switched (CS) domain 
and a Packet Switched (PS) domain. These two domains differ by the way they support user traffic, as explained 
bellow. These two domains are overlapping, i.e. they contain some common entities. A PLMN can implement only one 
domain or both domains. See TS 123 002 [18]. 

CS Domain: refers to the set of all the CN entities offering "CS type of connection" for user traffic as well as all the 
entities supporting the related signalling 

NOTE: A "CS type of connection" is a connection for which dedicated network resources are allocated at the 
connection establishment and released at the connection release. See TS 123 002 [18]. The entities 
specific to the CS domain are: MSC, GMSC, VLR. All the other CN entities defined in clause 4 and not 
defined as PS domain specific entities (see following subclause) are common to the CS and to the PS 
domains. See TS 123 002 [18]. 

domain: collection of physical or functional entities within an administrative domain which share a consistent set of 
policies and common technologies 

Domain IDentifier (DID): globally unique identifier of a domain 

NOTE: Domain identifiers may be mapped to the IP based Telephony Administrative Domain (ITAD) Numbers, 
registered by I AN A and used by the TRIP Protocol [3]. 

end-user: entity using the services of an IP based telephony service provider or transport network operator 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Consumer or business user without any technical knowledge of telecommunication technology using 
telecommunication terminals. See EG 201 219 [52]. 

end-user domain: collection of physical or functional entities under the control of an end-user which share a consistent 
set of policies and common technologies 

NOTE: See TS 101 314 [6]. 
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functional entity: entity in a system that performs a specific set of functions 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Grouping of service providing functions in a single location and a subset of the total set of functions 
required to provide the service. 

Functional Group (FG): collection of functional entities within a domain 

NOTE: In TIPHON systems functional groups are used to structure the necessary functionality to offer IP 
telephony services across domains. See TS 101 314 [6]. 

gateway functional group: functional group containing the functionality of a network functional group also the 
functionality necessary to connect calls to the SCN 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Gateway functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

home network functional group: functional group, which is aware of the service application subscribed to by the end- 
user 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Home network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

intermediate (transit) network functional group: functional group connecting the serving network functional group 
to the home network functional group 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: The intermediate network functional grouping is only present when the Serving network functional 
grouping and the home network functional grouping are not directly connected. 

information flow: interaction between a communicating pair of functional entities 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Interaction between a communicating pair of functional entities. 

interconnection function: functional entity connecting two networks having differing administrative policy such as 
Quality of Service (QoS) or addressing policy but employing the same signalling protocol, and transport technology, at 
the point of interconnect 

NOTE: SeeTS 101 314 [6]. 

interface: shared boundary between two communicating systems, devices or equipment 

IP Multimedia Subsystem (IMS): The IM subsystem comprises all CN elements for provision of IM services. The 
stage 2 of the IM subsystem is defined in ITU-T Recommendation Q.1214 [24]. 

IP network: packet transport network comprising one or more transport domains each employing the IP protocol 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Network that is accommodating IP and protocols related to IP (see EG 201 898 [53]). 
IP telephony: any telephony related service that is supported on a managed IP Network 

NOTE: See TS 101 314 [6]. 
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IP telephony service provider: service provider who offers IP based telephony services 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: The same business entity may act as both a transport network operator and an IP telephony service 
provider. 

network functional group: functional group containing the functionality required to establish a call between two 
terminals, a gateway and a terminal, or two gateways 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

packet flow/transport flow: stream of packets of the same type identified by common address and port numbers 

NOTE: The stream may contain either signalling information or content description together with media 
information. 

protocol: set of semantics, syntax and procedures, which govern the exchange of information across an interface 

PS Domain: The PS domain refers to the set of all the CN entities offering "PS type of connection" for user traffic as 
well as all the entities supporting the related signalling 

NOTE: A "PS type of connection" transports the user information using autonomous concatenation of bits called 
packets: each packet can be routed independently from the previous one. See TS 123 002 [18]. 

The entities specific to the PS domain are the GPRS specific entities, i.e. SGSN and GGSN. All the other 
CN entities defined in clause 4 and not defined as CS domain specific entities (see previous subclause) 
are common to the CS and to the PS domains. 

Public Land Mobile Network (PLMN): A Public Land Mobile Network (PLMN) is established and operated by an 
administration or Recognized Private Operating Agency (RPOA) for the specific purpose of providing land mobile 
telecommunications service services to the public. A PLMN may be regarded as an extension of a network (e.g. ISDN, 
corporate and public PDNs, etc); it is a collection of MSCs areas in CS domain and SGSN areas in PS domain within a 
common numbering plan (e.g. same National Destination Code) and a common routing plan. The MSCs are the 
functional interfaces between the PLMN and the fixed networks for call set-up in CS domain. The GGSN and the 
SGSN are the functional interfaces between the fixed networks and a PLMN for packet transmission in PS domain. 
Functionally the PLMNs may be regarded as independent telecommunications entities even though different PLMNs 
may be interconnected through the ISDN/PSTN and PDNs for forwarding of calls or network information. A similar 
type of interconnection may exist for the interaction between the MSCs/SGSNs of one PLMN (see TS 123 002 [18]). 
Telecommunications network providing services to mobile users (see TR 101 338 [54]). 

reference point: conceptual point at the conjunction of two communicating functional entities 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: A conceptual point at the conjunction of two non-overlapping functions that can be used to identify the 
type of information passing between these functions (see ETR 322 [55]). 

service domain: collection of physical or functional entities offering IP based telephony services under the control of 
an IP Telephony Service Provider which share a consistent set of policies and common technologies 

NOTE: See TS 101 314 [6]. 

serving network functional group: functional group that enables terminal functional groups to connect to an IP 
telephony service provide 

NOTE: SeeTS 101 314 [6]. 
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Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses 
circuit-switched technologies for the support of voice calls 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: The SCN may be a public network or a private network. 

terminal: endpoint within the user equipment on which signalling and media flows originate and/or terminate 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Equipment provided at the user side of the coincident S and T reference point (see EN 301 813-3 [56]). 
Device into which a UICC can be inserted and which is capable of providing access to UMTS services to 
users, either alone or in conjunction with a UICC (see TS 131 121 [57]). Device which is capable of 
providing access to services to users. Note the type of terminal is defined by the context (e.g. H.323 
terminal, GSM terminal, etc) (see TR 101 338 [54]). 

terminal functional group: functional group representing all the IP based telephony functionality within an end-user's 
terminal 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Terminal functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

ticket: a ticket is obtained through the registration session, when used in a call it provides the terminal/user with a 
means to show that a valid registration exists 

NOTE: See TS 101 314 [6]. 

transport domain: collection of transport resources sharing a common set of policies, QoS mechanisms and transport 
technologies under the control of a transport network operator 

NOTE: See TS 101 314 [6]. 

transport function: functional entity representing the collection of transport resources within a transport domain which 
are capable of control by a transport resource manager 

NOTE: See TS 101 314 [6]. 
transport network: collection of transport resources, which provide transport functionality 

NOTE: See TS 101 329-3 [58]. 
transport network operator: business entity operating a transport network 

NOTE: See TS 101 314 [6]. 
transport policy entity: functional entity that maintains the policies of a transport domain 

NOTE: See TS 101 314 [6]. 

Transport Resource Manager (TRM): functional entity that applies a set of policies and mechanisms to a set of 
transport resources to ensure that those resources are allocated such that they are sufficient to enable transport flows 
with QoS guarantees across the domain of control of the TRM 

NOTE: See TS 101 314 [6]. 

user equipment: equipment under the control of an end-user 

NOTE: See TS 101 329-3 [58]. 
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user profile: service specific information about a user of a service application 

NOTEl: SeeTS 101 314 [6]. 

NOTE 2: Ths is a label identifying a combination of one user interface profile, and one user services profile 

(see ES 201 915-1 [59] and TR 122 121 [60]). This is the set of information necessary to provide a user 
with a consistent, personalised service environment, irrespective of the user's location or the terminal used 
(within the limitations of the terminal and the serving network) (see TS 122 101 [61] and 
TS 122 233 [62]). 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ABAC Aggregate Bearer Admission Control 

ABM Aggregate Bearer Management 

AN Access Network 

AS Application Server 

AuC Authentication Centre 

BC Bearer Control 

BCF Bearer Control Function 

BG Border Gateway 

BGCF Breakout Gateway Control Function 

BSS Base Station System 

CC Call Control 

CN Core Network 

CR Call Routing function 

CS Circuit Switched 

CSCF Call Session Control Function 

DID Domain IDentifier 

DiffServ Differentiated Services 

DNS Domain Name Service 

DTMF Dual Tone Multi Frequency 

EIR Equipment Identity Register 

FG Functional Group 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

gprsSSF GPRS Service Switching Function 

GSM General System for Mobile communication 

gsmSCF GSM Service Control Function 

gsmSRF GSM Specialized Resource Function 

gsmSSF GSM Service Switching Function 

GSN GPRS Support Node 

HLR Home Location Register 

HREG Home Network Registration function 

HSS Home Subscriber Server 

lANA Internet Assigned Numbers Authority 

ICE Interconnect Function 

I-CSCF Interrogating CSCF 

IM IP based Multimedia 

IM-MGW IP based Multimedia - Media Gateway Function 

IMS IP Multimedia Subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

IPN IP Network 

IPTN IP based Telephony Network 

IREG Intermediate Network Registration function 

ISDN Integrated Service Digital Network 

IT AD IP based Telephony Administrative Domain 

IWF Interworking Function 

LPF Logical Port Function 
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MAP Mobile Application Part 

MC Media Control 

ME Mobile Equipment 

MGCF Media Gateway Control Function 

MGW Media Gateway Function 

MPLS Multi-Protocol Label Switching 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

MS Mobile Station 

MSC Message Sequence Chart 

MSF Mobile Storage Function 

MSS Multiservice Switching System 

MT Mobile Termination 

NECF Network Edge Control Function 

NGN Next Generation Network 

NPDB Number Portability Database 

NSICF Network Service Instance Control Function 

PCF Policy Control Function 

P-CSCF Proxy CSCF 

PDN Packet Data Network 

PLMN Public Land Mobile Network 

PS Packet Switched 

PSTN Public Switched Telephony Network 

QoS Quality of Service 

QoSM Quality of Service Management 

QoSP Quality of Service Policy 

RPOA Recognized Private Operating Agency 

SC Service Control 

SCN Switched Circuit Networks 

S-CSCF Serving CSCF 

SFGF Service Feature Gateway Function 

SGF Signalling Gateway Function 

SGSN Serving GPRS Support Node 

SIM Subscriber Identity Module 

SLF Subscription Locator Function 

SREG Service Network Registration function 

SubMF Sub-ordinate Management Function 

SupMF Super-ordinate Management Function 

TA Transport Accounting function 

TCAP Transaction Capabilities 

TE Terminal Equipment 

TF Transport Function 

TP Transport Policy 

TREG Terminal Registration function 

TRIP Telephony Routing over IP Protocol 

TRM Transport Resource Management 

UMTS Universal Mobile Telecommunication System 

USIM UMTS Subscriber Identity Module 

VLR Visitor Location Register 

VS Virtual Switch 

VSCF Virtual Switch Control Function 

VSF Virtual Switch Function 
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4 Basic concepts 

4.1 Overview of the NGN project 1 study 

A reference model needs to be developed and adopted by all concerned bodies. Work should be on the basis of the 
following action plan: 

1) Use the TIPHON reference model and build up from there (see TS 101 314 [6]: release 3 and beyond). 

2) Define benchmark user scenarios starting with initial examples from SPAR, IPFN, OSA. (Consider service 
control, presence and roaming captured in clause 6.3 below as a set of network capability features for NGN 
concept development). 

3) Determine architectural requirements, including the support of network security. 
This study covers the following topic: 

1) Architectural requirements have to be analysed to determine: 

This study will use the framework for Reference points for interconnection as defined by ITU-T SGI 3 in 
ITU-T Recommendation Y.140 [50] 

A mapping of "NGN" compliant protocols requirements (to be developed by the protocol experts groups: 
e.g. SPAN 13) to the existing reference points to identify the missing parts. 

Provide a context and basis for the protocol analysis to determine in the protocol working groups: 

1) if the existing protocols are sufficient; 

2) if the existing protocols require enhancing and define the enhancements; or 

3) if new protocols are required, define the new protocols. 

2) Different access networks are evolving in different ways. Alternative interoperability strategies for the near 
term has to be identified (The approach for the future should be to co-ordinate and harmonize them as far as 
possible.) 

3) Work for connection of a legacy terminal to an NGN compliant network: 

functions to support Legacy Terminals; 

support of NGN capabilities over Legacy Access Networks. 

4) Define capabilities for NGN-aware terminals (defined as SIP or H.323 based terminals) how they inter-operate 
needs to be studied. 

terminals with upgradeable operating systems and software platforms; 

software downloads; 

redundancy and Evolution of cost-reduced terminals; 

version negotiation and management; 

target roll out path for NGN compliant networks. 

This study includes analysis of: ISC, MSF, Parlay, 3GPP, 3GPP2, ETSI SPAN, ETSI TIPHON, IETF SIP, 
ITU-T SGs 9, 11, 13, 15 and 16, etc. All of these bodies have apart of a puzzle: 

• ISC is looking at decomposed switch architectures (Soft-switch products). 

• IETF SIP is defining the protocols and behaviour of a SIP proxy to establish call control between user agents. 

• IETF Sipping (SIP Interworking Working Group) is defining the Interworking of SIP and ISUP. 
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MSF is looking at architecture based on partitioning. Creating parameter sets for the Megaco architecture and 
initiating inter-working events. Mapping existing architecture into the MSF architecture (i.e. IMT 2000). 

Parlay, 3GPP CN5, JAIN and ETSI SPAN 12 are focusing on the development of a call control and service 
control API. 

3GPP is mainly focused on the UMTS radio access, mobile access to multimedia, and the SIP behaviour. 
Soft-switch and profiling required in the home network. 

ETSI TIPHON is focused on harmonized architectures and inter- working between ISDN, PSTN, SIP. 

ETSI SPAN is involved in the ETSI evolution of ISDN, interoperability and inter-working including BICC 
and CBC. 

ITU-T SGs 9, 11, 13, 15 and 16, are involved in Standardization of Terminal, Signalling Protocols, 
Architectures, Codecs, and Multimedia with respect to Signalling System number 7 and internet protocols. 



4.2 Functional planes 



TR 101 877 [8] describes an environment for communications services that encompasses multiple domains of control 
and technology. These concepts are inherited from the work of the ETSI Project TIPHON [6]. 

Figure 4. 1 expands upon [7] by identifying the following functional planes, each containing a high level grouping of 
functionality: 

Application; 

Control; 

Packet Transport; 

SCN, Switched Circuit Network; 

Management plane. 




Management 
Plane 



Application Plane 




Control Plane 



Transport Plane 




Figure 4.1 : Functional planes 

The SCN plane contains the functionality relating to the SCN. Part of the SCN plane is a component of the service 
abstraction layer as defined in [7] and part of the SCN plane is a component of the transport abstraction layer as defined 
in [7]. Architectures for SCNs are defined elsewhere therefore details of this functional plane are not considered further 
in the present document. 
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The application plane makes use of capabilities provided by the other functional planes and it contains functions to 
support telephony. The application plane is a component of the service abstraction layer as defined in [7]. The 
application plane contains functions and has information flows that support the Service capabilities defined in [1]. 

The Control plane makes use of capabilities provided by the other functional planes and it contains functions to support 
control of telephony, other end to end services and interactions of telecommunications services between the end users, 
the transport plane and the application plane. The control plane is a component of the service abstraction layer as 
defined in [7]. The control plane contains functions and has information flows that support the Service capabilities 
defined in [ 1 ] . 

The packet transport plane contains the functionality relating to the underlying packet transport and services in general 
use, e.g. DNS. The IP based transport plane is a component of the transport abstraction layer as defined in [7]. 

The management plane contains the network management functionality but relates also to QoS and security. The details 
of this functional plane are considered in [4] . 

4.3 Domains and functional groups 

TS 101 878 [1] defines a number of concepts and terms that are used in the present document. 

Domains are a collection of physical entities or functional entities under the control of a single administration which 
share a consistent set of policies and compatible technologies. 

TIPHON distinguishes three kinds of domains: end-user domains, service domains and transport domains. 



Management Plane 




TRM 

Transport Plan^ 



Figure 4.2: TIPHON Release 3 Functional Grouping 
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The End-User Domain is controlled by the end-user while the service domain is controlled by an IP based telephony 
service provider and the transport domain is controlled by a transport network operator. 

Functional groups are the constructs used in the present document to structure functionality necessary to offer IP based 
telephony services across domains. The mapping between domains and functional groups is shown in [1]. 

NOTE: There may not be a one-to-one mapping between application level domains and transport level domains. 

The following functional groups are identified in the end-user domain: 

• Terminal functional group: a functional group representing all the IP based telephony functionality within a 
user's terminal. Terminal functional groups may be classified as originating or terminating based upon their 
location within the topology of a specified call. 



• 



The terminal registration functional group: a functional group representing the registration within the user's 
terminal. 



The following functional groups are identified in the service domain: 

• Network functional group: a functional group containing the functionality required to establish a call between 
two terminals, a gateway and a terminal or two gateways. Network functional groups may be classified as 
originating or terminating based upon their location within the topology of a specified call. 

• Gateway functional group: a functional group containing the functionality of a network functional group also 
the functionality necessary to connect calls to the SCN. Gateway functional groups may be classified as 
originating or terminating based upon their location within the topology of a specified call. 

The network functional group represents all of the functionality of an IP-based application in support of the call. In 
fixed network environments the originating end-user always has a contract with the service provider controlling the 
service domain containing the originating network functional group and the terminating user with the service provider 
controlling the Service Domain containing the Terminating Network Functional Group. For mobility considerations this 
may not be the case. Therefore network functional groups are further divided into Serving Network Functional Group, 
Intermediate Network Functional group and Home Network Functional Groups where these are defined: 

• Serving Network Functional Group: a functional group that enables terminal functional groups to connect to a 
service provider. 

• The Intermediate (transit) Functional Group: a functional group that connects the serving network functional 
group to the home network functional group. The intermediate network functional group is only present when 
the serving network functional group and the home network functional group are not directly connected. 

• Home network functional group: a functional group, which is aware of the service application, subscribed to 
by the end-user. Home network functional groups may be classified as originating or terminating based upon 
their location within the topology of a specified call. 

The home network functional group and the serving network functional group may reside in the same network or in 
different networks. 

The IP transport plane functional group is arranged through a number of functional entities grouped into layers. The 
following layers are identified within the IP based transport plane: 

• transport service; 

• transport control; 

• transport flow. 

The IP transport plane functional group, utilizes general non-application specific parameters effecting transport and 
QoS. These parameters must be controlled and accounted to achieve the transport requirements requested by the 
application. Detailed description of these IP based Transport Plane entities TIPHON Release 3 transport layer is defined 
in [6]. For UMTS access to the IP based Transport Plane is defined via GPRS as defined in [14] to [22]. For UMTS this 
Transport layer is defined in a number of specifications [26] gives further direction as to where to find the transport 
specifications. 
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4.4 Functional decomposition of the IP control plane 

The architecture for the IP control plane implements the capabilities necessary for the IP telephony application. This 
architecture is defined in [6], see figure 4.2. 

The IP based telephony application architecture is described using objects. These objects are related to each other but 
may be instantiated and deleted separately. 

One or more objects, taken together, exhibit the behaviour of the functional entities described in the present document. 
The functionality in the IP based telephony application plane is distributed within functional layers based on object 
lifetime and object ownership. Each functional layer provides capabilities to adjacent layers. This grouping is useful to 
understand the functionality involved but does not imply any physical implementation. 

Where there is a requirement for an interface between functional entities a reference point is defined. 



5 Overview of the UMTS architecture 

To provide the mobile service as it is defined, it is necessary to introduce some specific functions. These functional 
entities can be implemented in different equipments or gathered. In any case, exchanges of data occur between these 
entities. This clause contains a selection of material extracted from [3]. 

5.1 The Core Network (CN) entities 

5.1 .1 Entities common to the PS and CS domains 
5.1 .1 .1 The Home Subscriber Server (HSS) 

The HSS is the master database for a given user. It is the entity containing the subscription-related information to 
support the network entities actually handling calls/sessions. 

A Home Network may contain one or several HSSs: it depends on the number of mobile subscribers, on the capacity of 
the equipment and on the organization of the network. 

As an example, the HSS provides support to the call control servers in order to complete the routing/roaming 
procedures by solving authentication, authorization, naming/addressing resolution, location dependencies, etc. 

The HSS is responsible for holding the following user related information: 

• User Identification, Numbering and addressing information. 

• User Security information: Network access control information for authentication and authorization 

• User Location information at inter-system level: the HSS supports the user registration, and stores inter-system 
location information, etc. 

• User profile information 

The HSS also generates User Security information for mutual authentication, communication integrity check and 
ciphering. 

Based on this information, the HSS also is responsible to support the call control and session management entities of the 
different Domains and Subsystems of the operator as shown in figure 5.2. 



£75/ 



23 



ETSI TS 102 261 VI. 1.1 (2003-09) 




MSC Server 


GMSC Server 


SGSN 



GGSN 



CSCF 



Figure 5.1 : Example of a HSS structure and basic interfaces 

The HSS may integrate heterogeneous information, and enable enhanced features in the core network to be offered to 
the appHcation and services domain, at the same time hiding the heterogeneity. 

The HSS consists of the following functionalities: 

• IP multimedia functionality to provide support to control functions of the IM subsystem such as the CSCF. It 
is needed to enable subscriber usage of the IM CN subsystem services. This IP multimedia functionality is 
independent of the access network used to access the IM CN subsystem. 

• The subset of the HLR/AUC functionality required by the PS Domain. 

• The subset of the HLR/AUC functionality required by the CS Domain, if it is desired to enable subscriber 
access to the CS Domain or to support roaming to legacy GSM/UMTS CS Domain networks. 

The organization of the subscriber data is outlined in TS 123 008 [19]. It also indicates which numbers, addresses and 
identifiers specified in TS 123 003 [17] are stored in HSS. 

5.1 .1 .1 .1 The Home Location Register (HLR) 

The HLR is shown in the Reference Architecture up to and including R4. 

The HLR can be considered a subset of the HSS that holds the following functionality: 

• The functionality required to provide support to PS Domain entities such as the SGSN and GGSN, through the 
Gr and Gc interfaces. It is needed to enable subscriber access to the PS Domain services. 

• The functionality required to provide support to CS Domain entities such as the MSC/MSC server and 
GMSC/GMSC server, through the C and D interfaces. It is needed to enable subscriber access to the CS 
Domain services and to support roaming to legacy GSM/UMTS CS Domain networks. 

5.1.1.1.2 The Authentication Centre (AuC) 

The AuC is shown in the Reference Architecture up to and including Rel-4. 

The AuC can be considered a subset of the HSS that holds the following functionality for the CS Domain and PS 
Domain: 

• The AuC is associated with an HLR and stores an identity key for each mobile subscriber registered with the 
associated HLR. This key is used to generate security data for each mobile subscriber: 

data which are used for mutual authentication of the International Mobile Subscriber Identity (IMSI) and 
the network; 

a key used to check the integrity of the communication over the radio path between the mobile station 
and the network; 
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a key used to cipher communication over the radio path between the mobile station and the network. 

• The AuC communicates only with its associated HLR over a non-standardized interface denoted the 
H-interface. The HLR requests the data needed for authentication and ciphering from the AuC via the 
H-interface, stores them and delivers them to the VLR and SGSN which need them to perform the security 
functions for a mobile station. 

5.1.1.1.3 HSS logical functions 

This clause provides a high level and not exhaustive description of HSS functionality. 
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Figure 5.2: HSS logical functions 

• Mobility Management 

This function supports the user mobility through CS Domain, PS Domain and IM CN subsystem. 

• Call and/or session establishment support 

The HSS supports the call and/or session establishment procedures in CS Domain, PS Domain and IM CN subsystem. 
For terminating traffic, it provides information on which call and/or session control entity currently hosts the user. 

• User security information generation 

• The HSS generates user authentication, integrity and ciphering data for the CS and PS Domains and for the IM 
CN subsystem. User security support. 

The HSS supports the authentication procedures to access CS Domain, PS Domain and IM CN subsystem services by 
storing the generated data for authentication, integrity and ciphering and by providing these data to the appropriate 
entity in the CN (i.e. MSC/VLR, SGSN or CSCF). 

• User identification handling 

The HSS provides the appropriate relations among all the identifiers uniquely determining the user in the system: CS 
Domain, PS Domain and IM CN subsystem (e.g. IMSI and MSISDNs for CS Domain; IMSI, MSISDNs and IP 
addresses for PS Domain, private identity and public identities for IM CN subsystem). 
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Access authorization 



The HSS authorizes the user for mobile access when requested by the MSC/VLR, SGSN or CSCF, by checking that the 
user is allowed to roam to that visited network. 

• Service authorization support 

The HSS provides basic authorization for MT call/session establishment and service invocation. Besides, the HSS 
updates the appropriate serving entities (i.e. MSC/VLR, SGSN, CSCF) with the relevant information related to the 
services to be provided to the user. 

• Service Provisioning Support 

• The HSS provides access to the service profile data for use within the CS Domain, PS Domain and/or IM CN 
subsystem.Application Services and CAMEL Services Support 

The HSS communicates with the SIP Application Server and the OSA-SCS to support Application Services connected 
to the IM CN subsystem. It communicates with the IM-SSF to support the CAMEL Services related to the IM CN 
subsystem. It communicates with the gsmSCF to support CAMEL Services in the CS Domain and PS Domain. 

5.1.2 Entities of the CS domain 

The UMTS CS-domain Supporting Nodes are described in annex B. 

5.1.3 Entities of tine PS domain 

The UMTS PS-domain (or GPRS) Support Nodes (GSN) are the Gateway GSN (GGSN) and the Serving GSN (SGSN). 
They constitute the interface between the radio system and the fixed networks offering packet based services. The GSN 
performs all necessary functions in order to handle the packet transmission to and from the mobile stations. 

5.1 .3.1 Serving GPRS Support Node (SGSN) 

The location register function in the SGSN stores two types of subscriber data needed to handle originating and 
terminating packet data transfer: 

• subscription information: 

the IMSI; 

one or more temporary identities; 

zero or more PDP addresses. 

• location information: 

depending on the operating mode of the MS, the cell or the routeing area where the MS is registered; 

the VLR number of the associated VLR (if the Gs interface is implemented); 

the GGSN address of each GGSN for which an active PDP context exists. 

The organization of the subscriber data in the SGSN is defined in TS 123 008 [19] and TS 123 060 [22]. 

The procedures for information transfer between the SGSN, the GGSN, the VLR and the HLR are defined in 
TS 123 016 [31] and TS 123 060 [22]. 

NOTE: When this improves the readability (e.g. when dealing with inter-releases handover), the term 2G-SGSN 
can be used to refer to an MSC Release 98 or prior, and the term 3G-SGSN can be used to refer to an 
MSC Release 99 or later. 
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5.1 .3.2 Gateway GPRS Support Node (GGSN) 

The location register function in the GGSN stores subscriber data received from the HLR and the SGSN. There are two 
types of subscriber data needed to handle originating and terminating packet data transfer: 

• subscription information: 

the IMSI; 

zero or more PDP addresses. 

• location information: 

the SGSN address for the SGSN where the MS is registered. 

The organization of the subscriber data in the GGSN is defined in TS 123 008 [19] and TS 123 060 [22]. 

The procedures for information transfer between the GGSN, the SGSN and the HLR are defined in TS 123 016 [31] and 
TS 123 060 [22]. 

5.1 .3.3 Border Gateway (BG) 

The Border Gateway (BG) is a gateway between a PLMN supporting GPRS and an external inter-PLMN backbone 
network used to interconnect with other PLMNs also supporting GPRS. The role of the BG is to provide the appropriate 
level of security to protect the PLMN and its subscribers. 

The BG is only needed in PLMNs supporting GPRS. 



5.2 The Mobile Station (IVIS) 



The mobile station consists of the physical equipment used by a PLMN subscriber; it comprises the Mobile Equipment 
(ME) and the Subscriber Identity Module (SIM), called UMTS Subscriber Identity Module (USIM) for Release 99 and 
following. The ME comprises the Mobile Termination (MT) which, depending on the application and services, may 
support various combinations of Terminal Adapter (TA) and Terminal Equipment (TE) functional groups. These 
functional groups are described in TS 124 002 [27]. 

5.3 IP based Multimedia (IM) Core Network (CN) Subsystem 
entities 

5.3.1 Call Session Control Function (CSCF) 

The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF). The P-CSCF 
is characterized by being the first contact point for the UE within the IM subsystem (IMS); the S-CSCF actually handles 
the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all IMS 
connections destined to a subscriber of that network operator. Further definitions of the P-, S- and I-CSCF are provided 
in [24]. 

5.3.2 IVIedia Gateway Control Function (IVIGCF) 

The MGCF: 

Controls the parts of the call state that pertain to connection control for media channels in an IM-MGW. 

Communicates with CSCF. 

Selects the CSCF depending on the routing number for incoming calls from legacy networks. 

Performs protocol conversion between ISUP and the IM subsystem call control protocols. 

Out of band information assumed to be received in MGCF and may be forwarded to CSCF/IM-MGW. 
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5.3.3 IP based Multimedia - Media Gateway Function (IM-MGW) 

NOTE: In the present document the term Media Gateway Function (MOW) is used when there is no need to 
differentiate between the CS domain entity and the IP based Multimedia CN Subsystem entity. When 
referring specifically to the CS domain entity the term CS-MGW is used. When referring specifically to 
the IP based Multimedia CN Subsystem entity, the term IM-MGW is used. 

An IM-MGW may terminate bearer channels from a switched circuit network and media streams from a packet network 
(e.g. RTP streams in an IP network). The IM-MGW may support media conversion, bearer control and payload 
processing (e.g. codec, echo canceller, conference bridge), it: 

• Interacts with the MGCF for resource control. 

• Owns and handles resources such as echo cancellers etc. 

• May need to have codecs. 

The IM-MGW will be provisioned with the necessary resources for supporting UMTS/GSM transport media. Further 
tailoring (i.e. packages) of the H.248 [42] may be required to support additional codecs and framing protocols, etc. 

5.3.4 Multimedia Resource Function Controller (MRFC) 

The MRFC: 

• Controls the media stream resources in the MRFP. 

• Interprets information coming from an AS and S-CSCF (e.g. session identifier) and control MRFP 
accordingly. 

• Generates CDRs . 

5.3.5 Multimedia Resource Function Processor (MRFP) 

The MRFP: 

• Controls bearers on the Mb reference point. 

• Provides resources to be controlled by the MRFC. 

• Mixes incoming media streams (e.g. for multiple parties). 

• Sources media streams (for multimedia announcements). 

• Processes media streams (e.g. audio transcoding, media analysis). 

5.3.6 Subscription Locator Function (SLF) 

The SLF: 

• Is queried by the I-CSCF during the Registration and Session Setup to get the name of the HSS containing the 
required subscriber specific data. Furthermore the SLF is also queried by the S-CSCF during the Registration. 

• Is accessed via the Dx interface 

The SLF is not required in a single HSS environment. An example for a single HSS environment is a server farm 
architecture. 

5.3.7 Breakout Gateway Control Function (BGCF) 

The Breakout Gateway control function (BGCF) selects the network in which PSTN breakout is to occur and - within 
the network where the breakout is to occur - selects the MGCF. 
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5.3.8 Application Server (AS) 



An Application Server (AS) i.e. SIP Application Server, OS A Application Server, or CAMEL IM-SSF connects to the 
IMS and offers value added services, which resides either in the user's home network or in a third party location. The 
third party could be a network or simply a stand-alone AS. 

The Serving-CSCF to AS interface is used to provide services. Two cases were identified: 

• Serving-CSCF to an AS in Home Network. 

• Serving-CSCF to an AS in a trusted External Network (e.g. Third Party or Visited). The S-CSCF does not 
provide authentication and security functionality for secure direct third party access to the IM Subsystem. The 
OSA framework provides a standardized way for third party access to the IM Subsystem. 

An Application Server may influence and impact the SIP session on behalf of the services supported by the operator's 
network. An AS may host and execute services. 

5.4 Signalling Gateway Function (SGW) 

The SGW performs the signalling conversion (both ways) at transport level between the SS7 based transport of 
signalling used in pre-Rel 4 networks, and the IP based transport of signalling possibly used in post-R99 networks 
(i.e. between Sigtran SCTP/IP and SS7 MTP). The SGW does not interpret the application layer (e.g. MAP, CAP, 
BICC, ISUP) messages but may have to interpret the underlying SCCP or SCTP layer to ensure proper routing of the 
signalling. 

5.5 IP related UMTS architectural configuration 

The basic configuration of a Public Land Mobile Network (PLMN) supporting GPRS and the interconnection to the 
PSTN/ISDN and PDN is presented in annex B. This clause presents the configuration nasedon IP signalling and user 
traffic interfaces which may be found in a PLMN. Implementations may be different: some particular functions may be 
gathered in the same equipment and then some interfaces may become internal interfaces. 

5.5.1 Configuration of IM Subsystem entities 

The configuration of IM CN Subsystem entities is presented in figure 6. In the figure, all the functions are considered 
implemented in different logical nodes. If two logical nodes are implemented in the same physical equipment, the 
relevant interfaces may become internal to that equipment. 

Only the interfaces specifically linked to the IM subsystem are shown, i.e. all the SGSN, GGSN and HSS interfaces 
depicted in figure 5.3 are still supported by these entities even if not shown. 
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Figure 5.3: Configuration of IIVI Subsystem entities (simplified) 

The Call Session Control Function (CSCF) can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating 
CSCF (I-CSCF). The P-CSCF is the first contact point for the UE within the IM subsystem (IMS); the S-CSCF actually 
handles the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all 
IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that 
network operator's service area. Further definitions of the P-, S- and I-CSCF are provided in TS 123 228 [30] and in 
TS 123 002 [18], see clause 5.3.1. 

In 3GPP the UMTS UE function is a device allowing a user access to network services. For the purpose of 3GPP 
specifications the interface between the UE and the network is the radio interface. A User Equipment can be subdivided 
into a number of domains, the domains being separated by reference points. Currently defined domains are the USIM 
and ME Domains. The ME Domain can further be subdivided into several components showing the connectivity 
between multiple functional groups. These groups can be implemented in one or more hardware devices. An example of 
such a connectivity is the TE - MT interface. Further, an occurrence of a User Equipment is an MS for GSM as defined 
in GSM TS 04.02, see TR 121 905 [1 1]. 

Figure 5.4 depicts an overall view of the functional architecture for services. 
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Legend: 

Bold lines: interfaces supporting user traffic; 

Dashed lines: interfaces supporting only signalling. 

Figure 5.4: Functional architecture for the provision of service in the IIVIS 

5.5.2 Configuration of signalling gateway function 

The signalling gateway function is used to interconnect different signalling networks i.e. SCTP/IP based signalling 
networks and SS7 signalling networks. The application layer (e.g. ISUP, BICC, MAP or CAP) is not affected. The 
signalling gateway function may be implemented as a stand alone entity or inside another entity. 




SGW 




Figure 5.5: Configuration of a signalling gateway function 

NOTE: SS7 application transport and SCTP/IP adaption protocols are not shown. 

5.6 PLMN basic interfaces and reference points 

The implementation of the mobile service with international roaming implies the exchange of data between the 
equipment involved in the service. The same No. 7 signalling network should be used to transfer these data and the 
call-related signalling information. 

5.6.1 Interfaces internal to the Core Network 

Description of the CS-Domain is included in annex B. 
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5.6.1 .1 Interfaces internal to the PS domain 

5.6.1 .1 .1 Interface between SGSN and HLR (Gr-interface) 

This interface is used to exchange the data related to the location of the mobile station and to the management of the 
subscriber. The main service provided to the mobile subscriber is the capability to transfer packet data within the whole 
service area. The SGSN informs the HLR of the location of a mobile station managed by the latter. The HLR sends to 
the SGSN all the data needed to support the service to the mobile subscriber. Exchanges of data may occur when the 
mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when 
some parameters of the subscription are modified by administrative means. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (TCAP) (see TS 129 002 [28]). 

5.6.1 .1 .2 Interface between SGSN and GGSN (Gn- and Gp-interface) 

These interfaces are used to support mobility between the SGSN and GGSN. The Gn interface is used when GGSN and 
SGSN are located inside one PLMN. The Gp-interface is used if GGSN and SGSN are located in different PLMNs. The 
Gn/Gp interface also includes a part which allows SGSNs to communicate subscriber and user data, when changing 
SGSN. 

Signalling on this interface uses the User Datagram Protocol, UDP/IP [46]. The Gn/Gp interface is defined in 
TS 129 060 [41]. 

5.6.1 .1 .3 Signalling Path between GGSN and HLR (Gc-interface) 

This optional signalling path may be used by the GGSN to retrieve information about the location and supported 
services for the mobile subscriber, to be able to activate a packet data network address. 

There are two alternative ways to implement this signalling path: 

if an SS7 interface is implemented in the GGSN, signalling between the GGSN and the HLR uses the Mobile 
Application Part (MAP), which in turn uses the services of Transaction Capabilities (TCAP) 
(see TS 129 002 [28]); 

if there is no SS7 interface in the GGSN, any GSN in the same PLMN and which has an SS7 interface 
installed can be used as a GTP to MAP protocol converter, thus forming a signalling path between the GGSN 
and the HLR. 

5.6.1 .1 .4 Interface between SGSN and EIR (Gf-interface) 

This interface is used between SGSN and EIR to exchange data, in order that the EIR can verify the status of the IMEI 
retrieved from the Mobile Station. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (TCAP) (see TS 129 002 [28]). 

5.6.2 IM Subsystem reference points 

5.6.2.1 Reference Point HSS - CSCF (Cx Reference Point) 

The Cx reference point supports information transfer between CSCF and HSS. 
The main procedures that require information transfer between CSCF and HSS are 

1) Procedures related to Serving CSCF assignment. 

2) Procedures related to routing information retrieval from HSS to CSCF. 

3) Procedures related to UE-HSS information tunnelling via CSCF. 
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5.6.2.2 Reference Point CSCF - UE (Gm Reference Point) 

This interface is to allow UE to communicate with the CSCF e.g.: 

register with a CSCF, 

call origination and termination, 

supplementary services control. 

The Gm reference point supports information transfer between UE and serving CSCF. The main procedures that require 
information transfer between UE and serving CSCF are 

procedures related to Serving CSCF registration, 

procedures related to User service requests to the serving CSCF, 

procedures related to the Authentication of the Application/Service, 

procedures related to the CSCF's request for Core Network resources in the Visited Network. 

5.6.2.3 Reference Point MGCF - IM-MGW (Mc Reference Point) 

See also clause 6.4.1.7. 

The Mc reference point describes the interfaces between the MGCF and IM-MGW, between the MSC Server and 
CS-MGW, and between the GMSC Server and CS-MGW. It has the following properties: 

full compliance with ITU-T Recommendation H.248 [42], baseline work of which is currently carried out in 
ITU-T Study Group 16, in conjunction with IETF MEGACO WG; 

flexible connection handling which allows support of different call models and different media processing 
piuposes not restricted to H.323 usage; 

open architecture where extensions/Packages definition work on the interface may be carried out; 

dynamic sharing of MGW physical node resources. A physical MGW can be partitioned into logically separate 
virtual MGWs/domains consisting of a set of statically allocated Terminations; 

dynamic sharing of transmission resources between the domains as the MGW controls bearers and manage 
resources according to the H.248 protocols. 

The functionality across the Mc reference point will need to support mobile specific functions such as SRNS 
relocation/handover and anchoring. It is expected that current H.248/IETF Megaco standard [42] mechanisms can be 
applied to enable this. 

5.6.2.4 Reference Point MGCF - CSCF (Mg Reference Point) 

The Mg reference point is based on external specifications, e.g. SIP [48]. 

5.6.2.5 Reference Point CSCF - Multimedia IP networks (Mm Reference Point) 

This is an IP interface between CSCF and IP networks. This interface is used, for example, to receive a call request 
from another VoIP call control server or terminal. 

5.6.2.6 Reference Point CSCF - MRFC (Mr Reference Point) 

This reference point allows interaction between an S-CSCF and an MRFC. 

The protocol used for the Mr reference point is SIP (as defined by RFC 2543 [48], other relevant RFC's, and additional 
enhancements introduced to support 3GPP's needs). 
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5.6.2.7 Reference Point MRFC - MRFP (Mp Reference Point) 

The Mp reference point allows an MRFC to control media stream resources provided by an MRF. 
The Mp reference point has the following properties: 

Full compliance with ITU-T Recommendation H.248 [42]. 

Open architecture where extensions (packages) definition work on the interface may be carried out. 

5.6.2.8 Reference Point CSCF - CSCF (Mw Reference Point) 

The interface allows the Interrogating CSCF to direct mobile terminated calls to the Serving CSCF. 

5.6.2.9 Reference Point GGSN-PCF (Go Reference Point) 

This interface allows the Policy Control Function (PCF) to apply policy to the bearer usage in the GGSN. 

The Policy Control Function (PCF) is a logical entity of the P-CSCF. If the PCF is implemented in a separate physical 
node, the interface between the PCF and the P-CSCF is not standardized. 

5.6.2.1 Reference Point CSCF - BGCF (Mi reference point) 

This reference point allows the Serving CSCF to forward the session to the Breakout Gateway Control Function for the 
purpose of interworking to the PSTN networks. 

The Mi reference point is based on external specifications i.e. SIP [48]. 

5.6.2.1 1 Reference Point BGCF - MGCF (Mj reference point) 

This reference point allows the Breakout Gateway Control Function to forward the session signalling to the Media 
Gateway Control Function for the purpose of interworking to the PSTN networks. 

The Mj reference point is based on external specifications i.e. SIP [48]. 

5.6.2.1 2 Reference Point BGCF - BGCF (Mk reference point) 

This reference point allows the Breakout Gateway Control Function to forward the session signalling to another 
Breakout Gateway Control Function. 

The Mk reference point is based on external specifications i.e. SIP [48]. 

5.6.2.13 Reference Point CSCF- SLF (Dx reference point) 

This interface between CSCF and SLF is used to retrieve the address of the HSS which holds the subscription for a 
given user. 

This interface is not required in a single HSS environment. An example for a single HSS environment is a server farm 
architecture. 

5.6.2.14 Reference Point to IPv6 network services (Mb reference point) 

Via the Mb reference point IPv6 network services are accessed. These IPv6 network services are used for user data 
transport. Note, that GPRS provides IPv6 network services to the UE, i.e. the GPRS Gi reference point and the IMS Mb 
reference point may be the same. 

5.6.2.1 5 Reference Point CSCF - AS (ISC reference point) 

This interface between CSCF and the Application Servers (i.e. SIP Application Server, OSA Capability Server, or 
CAMEL IM-SSF) is used to provide services for the IMS. 
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5.6.2.16 Reference Point HSS - SIP AS or OSA SCS (Sh reference point) 

The Application Server (SIP Application Server and/or the OSA service capability server) may communicate to the 
HSS. The Sh interface is used for this purpose. Details are described in TS 123 228 [30], clause 4.2.4. 

5.6.2.17 Reference Point HSS - CAMEL IM-SSF (Si reference point) 

The CAMEL Application Server (IM-SSF) may communicate to the HSS. The Si interface is used for this purpose. 
Details are described in TS 123 228 [30], clause 4.2.4. 

5.7 Reference points between the PLMN and other networks 

The reference points between the PLMN and other networks, including dedicated networks, are described in the 
49-series of Technical Specifications and in the 29-series of Technical Specifications. 

5.7.1 Reference point fixed networks - MSC 

The MSC is based on a normal ISDN exchange. It has, for call control, the same reference points as the fixed network 
exchanges. The signalling reference point considered in the Technical Specifications is related to the signalling system 
No. 7 User Parts TUP and ISUP associated to the circuits used for incoming and outgoing calls. 

5.7.2 Reference point GGSN - packet data networks (Gi reference point) 

This is the reference point between the GGSN and a packet data network. It may be an operator external public or 
private packet data network or an intra operator packet data network, e.g. for provision of IMS services. 



6 Mapping the UIVITS IIVIS architecture onto the 

TIPHON Call Control Architecture 

Call Control functions shall be present in all networks involved in handling a call. Instances of lower layer functions 
may be created or destroyed as needed for a particular call. Bearer Control functions shall not be created for networks 
that choose not to directly control functions in the IP transport plane. A Bearer Control function shall be created when 
bearer re-negotiation is required, however the Media Control function and IP transport plane functions may not be 
needed in all cases. 

For the simplicity only one Call control function is shown within each network. However, one network may include 
more than one function with a reference point similar to the inter-network reference point, e.g. C2. 

See clause 6 for details about the functional decomposition of the IP transport plane and [4] for details about the 
management plane. 

6.1 Scenario 

Both users are using an IP terminal. 
Two major traffic cases may be identified: 

• The first case: "Users at home" allows the calling user and the called user, registered directly with their home 
network, to obtain services from the originating network functional group. 

• The second case: "Roaming users", allows the calling user and called user, registered with their home network 
via a serving network functional group, to obtain services from their home network functional group. The 
serving network functional group shall in this scenario act as a proxy and forward messages from the user's 
terminal to the home network and vice versa. 
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NOTE: Combinations of the above two cases can exist and may be visualized by combining one call half in first 
case (e.g. originating terminal functional group + originating network functional group) with the other 
call half in second case (e.g. terminating network functional group + terminating terminal functional 
group). 

In the UMTS Architecture users are considered to be always able to roam. Hence the "AT Home" scenaron is not 
required to be shown. Clearly users registered "At Home" in their home network are still supported by the roaming case 
but the interactions between the Serving network functional group and the Home network FG are greatly simplified. 

Both the calling user and the called user are registered with their home network via a serving network. 
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NOTE 1 : For simplicity only tlie Serving network functional group and the Home network functional group are 

included in the Originating network functional group and the Terminating network functional group. Also an 
Intermediate network functional group may be present between them with reference points similar to the 
inter-network reference points e.g. C2. 

NOTE 2: The reference point Ag5 is the reference point A in [4] and reference point S5 In the present document. 

NOTE 3: Parts of the ABAC and the ABM function belongs to the Management Plane. Aggregate Bearer load 

control information flows between ABM and ABAC at N2 with the capability to provide admission control 
functionality based on aggregate bandwidth usage measurements and transport network QoS 
performance. 

Figure 6.1 : Reference points for the Scenario 0: roaming user 
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6.2 



Scenario 1 



The calling user is using an IP terminal, the called user is connected to the SCN. 
Two traffic cases may be identified: 

• The first case: "User at home", allows a user, registered directly to his home network, to obtain services from 
the Originating network functional group. 

• The second case: "Roaming user", allows a user, registered to his home network via a serving network 
functional group, to obtain services from his Home network functional group. The serving network functional 
group will act as a proxy, even though local services may be provided to the calling user. 

The calling user is registered to his home network through a serving network. 




NOTE 1 : For simplicity only tlie Serving network functional group and the Home network functional group are 
included in the Originating Network. Also an Intermediate network functional group could be present 
between them with reference points similar to the inter-network reference points e.g. C2. 

NOTE 2: The reference point Agg is the reference point A in [4] and reference point S5 in the present document. 

NOTE 3: Parts of the ABAC and the ABM function belongs to the Management Plane. Aggregate Bearer load 

control information flows between ABM and ABAC at N2 with the capability to provide admission control 
functionality based on aggregate bandwidth usage measurements and transport network QoS 
performance. 

Figure 6.2: Reference points for the Scenario 1 (roaming user) 
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6.3 



Scenario 2 



The calling user is connected to the SCN, the called user is using an IP terminal. 
Two traffic cases may be identified: 

• The first case: "User at home", allows a user, registered directly to his home network, to obtain services from 
the Terminating network functional group. 

• The second case: "Roaming user", allows a user, registered to the home network via a Serving network 
functional group, to obtain services from his Home network functional group. The Serving network functional 
group will in this case act as a proxy even though local services may be provided to the called user. 

The called user is registered to his home network via a serving network. 




NOTE 1 : The reference point Agg is the reference point A in [4] and reference point S5 In the present document. 

NOTE 2: For simplicity only the Serving network functional group and the Home network functional group are 
included in the Terminating Network. Also an Intermediate network functional group could be present 
between them with reference points similar to the inter-network reference points e.g. C2. 

NOTE 3: Parts of the ABAC and the ABM function belongs to the Management Plane. Aggregate Bearer load 

control information flows between ABM and ABAC at N2 with the capability to provide admission control 
functionality based on aggregate bandwidth usage measurements and transport network QoS 
performance. 

Figure 6.3: Reference points for the Scenario 2: roaming user 
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Multiservice switching forum: IVIULTI-PLANE system 
architecture 



7.1 Scope of the architecture 



A multi-plane system model has been selected as the basis of the Multiservice Switching System (MSS) architecture. 
The architecture employs a logical model, clearly identifying the areas where Implementation Agreements are 
necessary. Whenever possible, the model uses standards from the organizations mentioned earlier. 

An essential characteristic of the Architecture is its flexibility in terms of the technology chosen to implement 
functionality of each plane. In figure 7. 1 the Adaptation Plane provides the widest range of choices in terms of different 
technologies but there is also a choice of technology for the realization of the Switching Planes and the Control Planes. 
New technologies are allowed to evolve independently from each other in all three planes. To simplify interconnect 
between modules in different planes, the architecture makes use of standard interconnect protocols (ATM, 
SONET/SDH as well as IP/Ethernet for control for MSF Release 1). 

Within the vision of Multi-Service Switching, controllers in the Control Plane can share the resources of the Switching 
Plane and of the Adaptation Plane. By applying service management and policy mechanisms to switch resources, they 
can be separated or combined as required to support the network's applications. One important effect of the grouping of 
resources is the creation of virtual switches, each of which is paired with a controller in the Control Plane 
(see clauses 7.4 for detailed discussions of VS partitioning). 

Figure 7.1 illustrates the Adaptation, Switching, Control, Applications and Management Planes of the architecture. 
Starting from the bottom of figure 7.1, the Adaptation Plane supports the physical interface to a user or another network 
element. The Switching Plane supports the actual switching fabric by which physical interfaces are connected. The 
Control Plane provides the capability to manage network service events and provides control over both the adaptation 
and Switching Planes. Standard protocols are used in communicating between the Control Plane and the 
Switching/ Adaptation Planes. The Application Plane provides services that use the capabilities of the Control Plane and 
it also provides enhanced services which control the services realized within the Control Plane. 

It should be noted that the planar model is not meant to imply how functions will be physically layered in a multiservice 
environment. For example. Control Plane and Application Plane functions could be combined in a single physical 
element or in separated physical elements. 
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Figure 7.1 : Scope of the Multiservice Switching Architecture 

Subsequent clauses detail the functions and interfaces involved in each plane. The architecture covers interfaces and 
protocols between controllers of various types residing in the Control Plane and functions residing in either the 
Switching Plane or Adaptation Plane as shown via the dashed lines in figure 7.1. Each specific Adaptation Plane 
element (e.g. a voice or an ATM port) should be controlled by only one protocol. This decision simplifies both the 
adaptation element the controllers, since only a single protocol is required to control a specific Adaptation Plane 
element. The scope of the MSF also includes use of protocols between Control Plane processors, for example, use of 
signalling between a voice/SS7 controller and an ATM/SVC controller as shown in the Control Plane of figure 7.1. 

The protocol used to control a particular adaptation function is dependent upon the required functionality, complexity, 
and performance. For example, the architecture strives to make control of native ATM and ATM -based adaptation 
protocols (e.g. frame relay and circuit emulation) as efficient as possible. Where an adaptation function has a more 
complex and evolving set of requirements (e.g. voice and IP), adaptation specific protocols may be required. A single 
protocol should be employed to control a specific type of adaptation service. The port-to-port service provided by the 
Multiservice switch is a combination of the Adaptation and Switching Planes as established via the Control Plane. 
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7.2 



Functions and definitions 
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- Italicized reference points are not considered open reference points for release 1 . 

- Bearer transport reference points are not shown. 

I Z I - Management functions overlaid on functional architecture 
* The Partitioning Function maintains partition integrity between partitions of a 
partitioned entity. 

Figure 7.2: Reference architecture corresponding to functional definitions 

This clause provides descriptions of the planes, the functions within each plane, and the reference points. Figure 7.2 
identifies functional groupings within the MSF System Architecture. Reference points are defined between the 
identified functional groupings. 

7.2.1 Adaptation Plane description and functions 

The Adaptation Plane is responsible for providing access to a large variety of UNIs, SNIs and NNIs that a MSS 
(Multiservice Switching System) may support. Typical functions of the Adaptation Plane are: 

a) Processing real-time services (such as voice and video) and non-real time services (such as file transfer) into 
bit patterns and protocol formats for the Switching Plane to process and transport between ports. ATM AAL 1, 
2 and 5 adaptation and VoIP (RTP) are examples of standards that may be used by the Adaptation Plane in 
order to format information for the Switching Plane to process. 

b) Providing service-specific functions that do not directly alter user data on the interface. For example, 
classification and scheduling of the media stream to provide the required QoS, as well as policing and shaping 
the media stream to ensure that it adheres to the negotiated traffic contract. 

c) Performing ABR functions like EFCI marking and Resource Management (RM) cell processing. 

d) Replicating cells for point-to-multipoint (pt-mpt) connections. 

Adaptation Plane resources are either dedicated to a single controller, or shared between controllers. 
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Examples of dedicated resources are: 

• Time slots on TDM ports 

• VPI/VCI values on an ATM port 

• DLCI values on a FR port 
Examples of shared resources are: 

• Conference bridges 

• Tone receivers 

• Buffers 

7.2.1 .1 Logical Port Function (LPF) 

Each Logical Port Function (LPF) instance provides the necessary media mapping and service specific adaptation 
functions related to the incoming media stream. A LPF utilizes the set of physical resources (e.g. echo canceller) 
allocated by the Network Edge Control Function (NECF) to perform a defined adaptation task. It maps or transcodes an 
external media stream from a sub-network to the internal media stream routed by the specific switching function to 
another logical port or another functional entity. For associated signalling (e.g. ISDN, UNI, FR), the Signalling 
Gateway Function (SGF) is tightly related to the LPF in order to relay signalling to the associated control complex. An 
assumption is made that media streams are multiplexed/demultiplexed to the appropriate LPF instance. 

The LPF is also responsible for uniquely identifying data streams within the MSS. It maps received routing information 
to system internal routing information (tags, labels, etc.), and vice-versa. 

Management assigns an LPF to a Partition using the sm reference point. 

7.2.2 Switching Plane description and functions 

Functions of the Switching Plane within a MSS include: 

a) Providing basic cross-connect functionality between logical ports 

b) Forwarding user information using labels/tags 

c) Supporting a multiplicity of adaptation and switching elements under the domain of a single controller. This 
should include remotely located adaptation and switching elements reliably interconnected via standard 
interfaces hke SONET/SDH Automatic Protection Switching (APS). 

d) Providing an interface to the Adaptation Plane. When the switching and Adaptation Plane are implemented as 
separate physical elements, the interface should be based upon standard physical interfaces. 

e) Replicating data for point-to-multipoint (pt-mpt) connections providing a common switch control interface to 
one or more controllers. 

f) Partitioning and sharing resources within the switch. 

In MSF Release 1, the Switching Plane is responsible for the cell switching function within the Multiservice Switching 
System. Functions based upon cell switching include: 

a) Providing an ATM-cell-based interface to the Adaptation Plane. 

b) Switching cells or flows based on VPIA^CI/CID fields. 

c) Queuing, servicing, and performing cell header functions based on VPI/VCI values, the ATM Service 
Category (i.e. CBR, rt-VBR, nrt-VBR, UBR, ABR, GFR), and the traffic parameters of the ATM connection. 

d) Replicating cells for point-to-multipoint (pt-mpt) connections. 

e) Performing ABR functions like EFCI marking and Resource Management (RM) cell processing. 

f) Merging cells in a multipoint-point (mpt-pt) configuration in support of MPLS. 
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g) Providing a common switch control interface to one or more controllers, 
h) Partitioning and sharing resources within the switch, 
i) Processing of O&M cells (e.g. loopbacks). 

7.2.2.1 Virtual Switch Function (VSF) 

Any entity may be partitioned into one or more subsets of resources. A partition of switch resources is called a Virtual 
Switch Function (VSF), and is an arbitrary subset of switch resources that can be controlled as a unit. A partitioned 
switch entity may be a single physical switch, or a group of inter-connected physical switches, or other VSFs. 

Switching resources are responsible for the switching of media streams from one (logical) port to another or to a 
functional entity. The switching resources may provide packet switching, frame switching, cell switching etc. 

In addition, the VSF is responsible for conveying state and availability information of its resources to the Virtual Switch 
Control Function (VSCF). 

7.2.3 Description of Functions spanning the Switching and Adaptation 
Planes 

7.2.3.1 Partitioning Function (PF) 

Management creates a VSF (Virtual Switch Function) using the sm reference point by specifying the switch resources 
that are to make up the partition. These resources include LPFs, physical port resources such as bandwidth and buffer 
space, and physical switch resources such as forwarding table space. 

The Partitioning Function maintains partition integrity between partitions of a partitioned entity. Integrity is maintained 
in terms of the actual partitioned resources as well as in terms of the flow of control between a Controller and its 
controlled partition. The partitioned entity enforces its defined partitions in real-time by not accepting requests on LPFs 
and/or switch resources allocated by management to partitions other than those allocated to the requesting Controller. It 
is not implied that the Partitioning Function is implemented in any particular way e.g. either centralized or distributed. 
In the case of distributed implementation each of the partitions is charged with coordination with all the other partitions 
for the purpose of maintaining integrity as required above. 

The partitioned entity performs any necessary re-mapping of information in the Virtual Switch domain to references in 
the partitioned physical switch domain. This re-mapping between virtual and physical domains allows controllers to 
stay unaware of partitioning. 

Reference point sm is used for interaction with the Superordinate Management Function while np, vsc and sp are used 
to access the partitions. 

7.2.4 Control Plane description and functions 

The Control Plane is responsible for the routing of traffic between Switching Plane, Adaptation Plane and Applications 
Plane within the switching system. The Control Plane allocates Switching Plane and Adaptation Plane resources. 
Specific functions of the Control Plane include: 

a) Routing and rerouting of traffic between switching complexes within a MSS as well as connections between 
MSSs. 

b) Controlling the establishment of label mappings (e.g. VPIA'^CI) between port interfaces connected via the 
Switching Plane. 

c) Commands establishment, modification and release of connections or flows. 

d) Assign traffic and QoS parameters for each connection or flow. 

e) Controlling the Adaptation Plane functions. 

f) Terminating and originating signalling from Trunk, NNI and UNI ports in conjunction with the Adaptation 
Plane. 
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g) Providing interfaces to the Applications Plane. 



h) Support a variety of services accessed by multiple signalling protocols for voice, data and video services such 
asSS7, Q.931,H.323, etc. 

i) Performing admission control and traffic engineering for the network. 

j) Providing call level statistics, Call Detail Records and alarms. 

k) The Control Plane should be modular and may include several, independent controllers. For example, it may 
include separate controllers for Voice/SS7, ATM/SVC, and even IP/MPLS services as shown in figure 6.1. 

1) Receiving signalling information from each port and passing the information to other entities in the Control 
Plane. This includes capturing and passing D channel and SS7 signalling information as well as monitoring for 
in-band events such as DTMF tones on voice interfaces. 

m) Negotiating connection and adaptation parameters, such as bit rate and codec type, with the peer Adaptation 
Plane Element at the far-end MSS. For example, the H.245 protocol controls video or voice coding algorithms 
and bit rates at call establishment time and on the fly during the connection. The Adaptation Plane shall 
provide control and reporting functions to the Control and Management Planes appropriate for these 
negotiation protocols. 

7.2.4.1 Network Edge Control Function (NECF) 

The NECF requests the creation, modification, and termination of LPF (Logical Port Function) instances. The NECF is 
responsible for sending and receiving control information to and from a LPF regarding the media streams and other 
services (e.g. encryption) on those streams that it supports. This function tracks resource utilization and allocates 
resources (e.g. echo cancellers, tone detectors, etc.) to the logical ports. The NECF may allocate resources and apply 
services based on policy. 

7.2.4.2 Virtual Switch Control Function (VSCF) 

The VSCF controls and monitors the VSF (Virtual Switch Function) and LPFs (Logical Port Functions) within a 
Partition. The VSCF provides the required cross-connect information, including traffic and QoS information, across the 
VSF from one LPF instance to one or more LPF instances using the vsc reference point. It receives information about 
the switching function and propagates this information to other functions that may change state as a result (i.e. BCF). 
The VSCF communicates the required service category and traffic parameter requirements to the LPF in order to 
provide QoS and SLA's using the sp reference point. The VSCF may also provide other control information to the LPF; 
for example, label mapping. Note that any instance of an LPF is controlled by either a VSCF or an NECF (Network 
Edge Control Function). 

7.2.4.3 Bearer Control Function (BCF) 

The bearer control function is a functional block containing the logic for establishing, modifying and releasing 
end-to-end bearers between end point(s) (i.e. LPFs) of a bearer connection. A given MSS could have none, one or any 
BCFs. In a MSS, the BCF interacts with the appropriate instance of the NSICF and receives the information required to 
setup a bearer connection. The BCF may perform one or more of the following functions: 

a) Manages and maintains the state of links under its control. 

b) Establishes, manages and maintains the state of the required bearer path(s) for a specific NSICF (Network 
Service Instance Function) request and communicates this state to the NSICF. This includes all links in a 
pt-mpt network service instance. 

c) Signalling to peer entities (e.g. PNNI, MPLS). 

If Topology exchange information is required across the ic reference point: 

a) Obtains and maintains network topology information as related to peering and hierarchy. 

b) Manages and maintains the reachability state of end-to-end network paths. 

c) Manages and maintains the availability of network capacity and bandwidth. 



£75/ 



44 ETSI TS 1 02 261 V1 .1 .1 (2003-09) 

d) Provides updates to the NSICF about route availability in order to keep route updates accurate based on 
current availability. 

If local switch control is performed by going through the BCF: 

a) Establishes cross-connect/switching via the VSCF (Virtual Switch Control Function). 

7.2.4.4 Network Service Instance Control Function (NSICF) 

The NSICF contains the logic and information to establish, maintain, modify, and release a network service instance. 
Some examples of network service instances include a context, circuit switched calls (e.g. PSTN connection) and a flow 
(e.g. MPLS). It should be noted that the NSICF will act in different capacities depending on the type of network service 
instance being managed. For example an NSICF may provide basic ATM SVC service , interworking between N-ISDN 
Q.931 and B-ISDN Q.2931, interworking between FR and ATM signalling, or support for IP over MPLS. Therefore, 
the following capabilities may, or may not, be used in all service examples. See clause 4 for these and other examples. 
The NSICF performs one or more of the following functions: 

a) Applies services/applications, screening, and policy either directly or indirectly via the SFGF (Service Feature 
Gateway Function) which provides additional network-based services. 

b) Determines or obtains the address and routing options for reaching the destination end point(s) and may select 
the route to be used. 

c) Identifies the control signalling, bearer signalling, and address requirements of a networks service instance and 
determines the network interworking requirements if required. 

d) Terminates and Originates signalling (ix or ia flows) or provides the signalling interworking in order to map 
originating signalling to terminating signalling (ic to ia flows). 

e) Maintains information on the availability of path(s) to reach endpoint(s) based on routing information 
exchanged as well as from updates from the bearer control function. 

f) Provides information that is used in billing. 

g) Requests the use of adaptation resources that are required in order to deliver the service (e.g. echo cancellers, 
tone generators, tone receivers etc.). 

h) Maintains service instance state information. 

i) Negotiate service instance characteristics with its peer. 

j) Establishes a cross-connect/switching via the VSCF (Virtual Switch Control Function). 

The NSICF uses the NECF (Network Edge Control Function) and the BCF (Bearer Control Function) to establish, 
maintain, and release the bearer(s) of the associated network service instance. The NSICF exchanges control and 
signalling information with other NSICFs directly or via a SGF (Signalling Gateway Function). 

7.2.4.5 Signalling Gateway Function (SGF) 

The Signalling Gateway Function is the functional block that processes signalling, entering and exiting a MSS 
(Multiservice Switching System). Mandatory is to map, relay or tunnel the signalling. The SGF may also screen or 
terminate the associated signalling. The action taken by the SGF can be different depending upon whether it performs a 
transport function or a control signalling function. After processing incoming signalling data, the SGF will deliver 
control signalling information to the appropriate instance of the NSICF (Network Service Instance Control Function) 
via the appropriate transport mechanism. In general, the SGF maintains only enough information about the call state to 
manage the protocol interfaces. 

At lower layers, typically layer 2, it is the intent of the SGF to convert incoming signalling to a minimal set of common 
lower layer protocols. For example, Q.921 messaging may be "terminated" at the SGF and "mapped" to SIGTRAN 
SCTP. When performing a control signalling function, the SGF may use the "relay" capability when the control 
signalling systems are the same on both sides of the SGF. For example, if a user is originating signalling on an ATM 
UNI and the ATM UNI is the signalling mechanism between a physical gateway and a physical controller, then the 
originating signalling may simply be relayed to the NSICF. 
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The SGF may use the "tunnel" capability when the lower layer protocol has the ability to encapsulate the entire 
originating control signalling in the payload of another lower layer protocol. For example, if a user is originating Q.931 
control signalling, the complete Q.931 message may be tunnelled over SIGTRAN SCTP. The SGF may use the "map" 
capability when mapping originating control signalling to a peer control layer signalling protocol. 

In addition, the SGF may terminate or screen the incoming and exiting signalling stream. The SGF may use the "screen" 
capability in order to determine whether a specific control signalling IE is needed for further use. In conjunction, the 
SGF may also "terminate" certain control signalling lE's as defined by a certain implementation where there is no need 
to transport the lE's to for further network or user processes. For example, if a user originates an international variant of 
Q.931, it might "screen" the originating message, "terminate" one or more lE's that are not needed by the 
implementation for network or user processes, and then "map" the remaining lE's into standard Q.931 for transport over 
SIGTRAN SCTP to the NSICF. 

7.2.5 Application Plane description 

The applications plane will include a wide variety of services at many "levels". Some of these services will implement 
their own service control logic and will be accessed directly in the applications plane, others may be triggered from the 
Control Plane as is the case in traditional voice. Examples of these services include but are not limited to the following: 

1) Information and Content Services. 

2) Virtual Private Networks (VPNs) for voice and data. 

3) Voice Services. 

4) Video on Demand. 

5) Group Based Multimedia Services (N-way multimedia calls, WhiteboardApplications,...). 

6) Electronic Commerce and Call Centres. 

7) Multiplayer real-time network gaming. 
Specific functions of the Apphcations include: 

a) Messaging services such as email and voice mail. 

b) Processing services such as automatic speech recognition and credit card processing. 

c) Directory enabled services such as Freephone or toUfree number translation, local number portability, single 
number follow-me services for voice. 

d) Custom Local Area Signalling Services (CLASS) services such as distinctive call waiting, selective call 
forwarding for voice. 

e) IP naming and addressing services including DNS, DHCP, RADIUS service. Value-added IP telephony 
services such as virtual second line, web-800. 

f) Policy services. 

g) Directory services. 

7.2.5.1 Service Feature Gateway Function (SFGF) 

The SFGF is a functional block allowing access to intelligent network services and other network provided applications. 
It also allows directly signalled services in the Application Plane to access the Control Plane functionality. 
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7.2.6 Management Plane description and functions 

The Management Plane includes management functions, MIBs and interfaces within a MSS (Multiservice Switching 
System). Typical functions of the Management Plane include: 



Fault management. 
Configuration management. 
Accounting management. 
Performance management. 
Security management. 



The MSF Management Plane complements existing standards with functions, MIBs and interfaces that are required by 
the MSF Architecture. These new requirements, in part, stem from the fact that the MSF reference architecture defines a 
VSF (Virtual Switch Function), responsible for partitioning of switching resources into VSs (Virtual Switches). This 
allows VSs to be created on some set of switches in the network to form a virtual network. Each virtual network (the 
VSs that make up the network) can be controlled by an independent Control Plane that should not be aware that it is 
controlling virtual switches rather than physical ones. Similarly, each virtual network can be managed by a separate 
network manager that need not be aware of the fact that it is managing a virtual network and not a physical one. In this 
environment, management functions are required on two levels: the first is the management of the Switch Function and 
the VSF, and second is the management of individual VSs. The former is referred to as the Super-Ordinate Level of 
management, whilst the latter is referred to as the Sub-Ordinate Level. Figure 7.3 is the baseline MSF Switch 
Management reference. 
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Figure 7.3: Management plane: a super-ordinate instance of management logic offered 
to three instances (A, B and C) of subordinate management logic 
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7.2.6.1 Super-ordinate Management Function (SupMF) 

Management functions are required on the super-ordinate level to: 

• Allow the creation, modification, and deletion of VSs (Virtual Switches). 

• Partition and virtualize the management information and functions presented to the sub-ordinate management 
function corresponding to each VS. 

• Manage the physical hardware. This allows the manager to perform FCAPS functions against the switch 
hardware. 

7.2.6.2 Sub-ordinate Management Function (SubMF) 

On the sub-ordinate level, management is required per VS to allow a controller to perform FCAPS functions on the VS. 
The super-ordinate and sub-ordinate management requirements lead to the need for two types of Switch Management 
MIBs and the two reference points that the MSP will standardize (see clause 7.3.1.5). Note that throughout the present 
document the term MIB is used either to mean the management data maintained by an agent (the CMIP definition of the 
term) or to mean the description of some of this data (the SNMP definition of the term). 



7.3 Interfaces and reference points 



A Multiservice network requires the interaction of multiple switching systems operating at several planes in order to 
deliver a complete set of user services. The role of the MSF is to specify the protocols and interfaces used within an 
MSS (Multiservice Switching System). The inter -plane interfaces between the Management, Control, Switching and 
Adaptation Planes are described in clause 7.3.1. While interfaces between the Application and Control Planes are 
beyond the scope of the first release of the MSF Architecture, future releases of the architecture are expected to look at 
APIs and protocols between the Application and Control Planes. 

The MSF also has a role to aid in the selection of protocols and interfaces to be used between MSSs. These protocols 
and interfaces, defined outside the MSF by other standardization organizations, are described in clause 7.3.2. In 
particular. Control Plane to Control Plane protocols are defined by the ATM Forum (UNI, PNNI, AINI), ITU-T (DSSl, 
DSS2, ISUP, B-ISUP, BICC, H.323, Q.2111) and the IETF (SIP, MPLS, OSPF, BGP, SIGTRAN). Adaptation Plane to 
Adaptation Plane protocols are also defined by various bodies. 

This clause describes reference points between functions across a boundary between planes in the MSF Architecture for 
a potential requirement to specify a protocol and an interface to implement the interaction between the respective 
functional blocks. The specifications for these inter-plane interfaces and protocols will be defined in the respective MSF 
Implementation Agreement for those interfaces. See clause 5.6 for additional information. 

7.3.1 Inter-plane interactions 

This clause describes the reference points from figure 6.2 that cross planar boundaries. These are sometimes called 
vertical interfaces. 

7.3.1 .1 Adaptation Plane - Control Plane 

The Adaptation Plane shall support a range of service interfaces between Control Planes, including UNIs and NNIs for 
Voice, IP, Frame Relay, Circuit Emulation and ATM services. Each service has a distinct set of attributes and signalling 
requirements that must be supported by the Adaptation-Control Plane interface (np or sp reference points). The MSF 
shall define a set of Adaptation-Control Plane protocols that allow the support of this full range of services. These 
protocols shall enable both the relaying of service signalling information as well as control of the Adaptation Plane 
functions. In the first release, MEGACO/H.248 is the protocol for providing Voice and N-ISDN services between the 
Adaptation and Control Planes, while GSMPv3 is the protocol for providing frame relay, ATM, MPLS and circuit 
emulation services. 
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Edge Control Signalling reference point (np): 



This signalling association provides the signalling necessary to request the creation, modification, status or termination 
of a designated logical port session instance. One or more media could be handled within a logical port session. These 
media could be multiplexed and carried on a single path through the switch function. The signalling messages have the 
capability of adding and deleting media streams to the logical port session instance. 

Switch Port Signalling reference point (sp): 

Via information flowing across this reference point the virtual switch function conveys information to the logical port 
function that establishes a correlation between labels associated with external data-flows. An example is the conveyance 
of traffic descriptor information to enable the LPF (Logical Port Function) to perform policing, shaping and provide the 
required quality of service. Furthermore, some traditional broadband services may also have the adaptation control 
realized across the sp interface. Examples of these services would be ATM, FR, CES, and MPLS. 

The protocol requirements for interfaces supporting the np and sp reference points are specified in clause 3.4 of [49]. 

7.3.1 .2 Switching Plane - Control Plane 

The MSF architecture supports multiple independent controllers controlling logical switch partitions of a physical 
switch. The VSF (Virtual Switch Function) is responsible for insuring the integrity of a switch that has been partitioned 
into multiple virtual switches. 

The protocol requirements are specified in clause 3.4 of [49]. 

Virtual Switch Control Signalling reference point (vsc): 

This signalling association provides for the creation, modification, status, or termination of a connection path between 
logical ports. A connection may be point-to-point, point-multipoint, multipoint-point, or broadcast. Point-point 
connections may be unidirectional or bi-directional. 

7.3.1 .3 Switching Plane - Adaptation Plane 

The Adaptation and Switching Planes are coordinated by the Control Plane via collaboration of the various control 
functions (NSICF, NECF, BCF, VSCF) as depicted by the MSF functional architecture. No reference point is defined 
between the Switching and Adaptation Planes in this version of the MSF Architecture. 

7.3.1 .4 Control Plane - Application Plane 

The MSF architecture supports a multiservice switching system communicating with applications over the sa and sg 
reference points. These reference points also allow applications in the Applications Plane to access the Control Plane 
functionality. Communication between the Control and Applications Plane may use open software APIs or open 
standardized physical interfaces. The MSF has not chosen to address the standards associated with these reference 
points as part of Release 1, but they are candidates for being addressed in future releases. It is assumed that where 
enhanced "off-board" services are required for Release 1, existing open standards will be utilized (e.g. AIN, CS-1, etc.). 

Service Access SignaUing reference point (sa): 

This signalling association provides the transport of service events, requests and responses between the NSICF 
(Network Service Instance Control Function) and the SFGF (Service Feature Gateway Function). 

Service Access Gateway Signalling reference point (sg): 

This signalling association provides the transport of service requests and responses between external customers or 
networks and the applications plane via the SGF and the SFGF. 

Example of sg applied to SS7 INAP/ SIGTRAN mapping: 

IETF SIGTRAN SCTP, being developed by the IETF to transport SS7 INAP signalling messages over an IP transport 
network, is an example of a "sg" interface. SS7 INAP signalling arriving at SGF may be transported using IETF 
SIGTRAN SCTP to a SFGF. 
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7.3.1 .5 Management Plane- Switching and Adaptation Plane 

The MSF leverages several industry standards and agreements regarding management. What is specific for the MSF is 
the standardization of new MIBs required by the MSF Architecture and new MSF specific management interfaces (over 
reference points sm and vsm as shown in figure 6.3). The only interface between the management and the Adaptation 
and Switching Planes is provided through MIBs that offer an object abstraction of the Adaptation Plane through 
proprietary agents. The MSF will use industry standard network management protocols to implement the sm and vsm 
reference points and will specify protocol independent MIBs for the VS MIB and Partition Management (Partitioning 
MIB). 

Three reference points in the Management Plane are identified. In addition, management flows occur at the SCI 
interface as well: 

Switch Management reference point (sm): 

The sm reference point enables the management of the switch through the following MIBs. These MIBs are referred to 
as the Switch Management MIB: 

• The Switch Partitioning MIB is used specifically for configuration of VSs. Configuring a partition entails the 
specification of the resources that it contains. 

• The GSMPv3 MIB is used specifically for management of the SCI instances presented by a switch to a 
controller. 

Other standardized MIBs such as MIB I, MIB II, AToM MIB are used for the exchange of aggregated FCAPS 
management information relating to the underlying switching function (physical switch). 

An interface for the sm reference point is subject to MSF standardization. 

Virtual Switch Management reference point (vsm): 

The vsm reference point is presented once for each VS (Virtual Switch) created using the Partitioning MIB. Each 
instance of the vsm (each VS MIB) presents, to a sub-ordinate management function, a subset of the Switch MIB, 
which contains FCAPS information for one VS. 

An interface for the vsm reference point is subject to MSF standardization. 

7.3.1 .6 Management - Control Plane 

The MSF Architecture is intended to allow for widest possible choice of technologies to be used in the Control Plane. 
The development of new controllers and their standardization is though beyond the scope of MSF in Release 1. 

Virtual Switch Control Management reference point (vscm): 

Each sub-ordinate management function manages its corresponding VSCF (Virtual Switch Control Function) over the 
vscm. The management of controllers is specific to the type of controller. 

An interface for the vscm reference point is NOT subject to MSF standardization in Release 1. 



7.3.2 Intra-plane interactions 



This clause describes the reference points from figure 6.2 within a single plane. These are sometimes called horizontal 
interfaces. 

7.3.2.1 Control Plane 

7.3.2.1 .1 Control - Control Plane, between same functions 

This clause describes reference points within the Control Plane categorized by whether they exist between the same 
function or between different functions. 
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At least the following Control-Control Plane interfaces and protocols operate between switching systems, as defined by 
the following bodies: 

• ATM Forum (e.g. UNI, PNNI, AINI) 

• IETF (e.g. MPLS LDP, OSPF, BGP, RSVP, IS-IS, RIP) 

• ITU-T (e.g. DSSl, DSS2, ISUP, B-ISUP. BIC, TUP) 

The MSF shall work to ensure that the routing and connection control protocols specified by these bodies can be 
supported by the MSF architecture. Similarly, the MSF shall work to support a relevant set of UNIs, SNIs and NNIs 
defined by these bodies. 

Inter-NSICF Signalling reference point (ia): 

This signalling association provides the necessary signalling to request the establishment, modification and release of 
service instances and to transfer service instance information between instances of the NSICF (Network Service 
Instance Control Function). 

Inter-MSS Bearer Control Signalling reference point (ic): 

This signalling association provides the necessary signalling to request the establishment, modification and release of 
consistent local bearer mappings (e.g. MPLS LDP) between instantiations of the BCF (Bearer Control Function). 

External control signalling (ix): 

This signalling association provides the necessary signalling for interconnecting different networks and/or technologies. 
It is anticipated that this signalling will support both call control and bearer control information. Some examples of 
interfaces supporting the "ix" information are SS7-ISUP signalling links, ISDN D-channel, VPI/VCI 0/5 for ATM 
SVCs, DLCI for FR SVCsand BGP. 

All of these reference points address the information carried in layer 3 signalling and routing protocols assigned with 
them in a physical realization. The ix reference point interfaces to the SGF (Signalling Gateway Function), which then 
interfaces to the NSICF (Network Service Instance Control Function) via a SGF using the st reference point. The SGF 
handles the lower layers of the signalling and routing protocols. Often, the MSF architectural model inserts an SGF at 
the interface between a network and a subscriber or between provider networks in order to establish the correct 
reference point model. 

7.3.2.1 .2 Control Plane, between different functions 

Bearer Control Signalling reference point (be): 

This signalling association provides the necessary signalling interaction between the NSICF (Network Service Instance 
Control Function) and the BCF (Bearer Control Function) to request and indicate the establishment, modification or 
release of an end to end bearer between MSS edge nodes. 

Signalling Transport Signalling reference point (st): 

This signalling association provides the transport of incoming and outgoing call and bearer signalling between the 
Signalling Gateway Function and Network Service Instance Control Function. 

Example of st applied to PSTN-ATM Interworking: 

SIGTRAN SCTP, being developed by the IETF, is one example of a "st" interface. SS7 and ISDN D-channel signalling 

are examples of common channel signalling that could be transported using IETF SIGTRAN SCTP or Q.21 1 1 . 

A second example of st applied to PSTN-ATM Interworking: 

Channel Associated Signalling (CAS) could be an example of signalling obtained from a Signalling Gateway Function 

(that is realized as part of the physical port) that could be transported over st. 

Example of st applied to ATM SVC Service: 

The SGF relays customer ATM SVC signalling from the assigned VPI/VCI to the NSICF that handles ATM SVC 
services. The customer initiates a request for a SVC via UNI signalling to an edge ATM switch. A cross-connect in the 
switch redirects the UNI to the SVC service controller where proxy signalling will be used to fulfil the SVC request. 
This cross-connect is a physical realization of the SGF where the SGF uses its relay capability. The redirection of the 
UNI constitutes another example of the signalling transport (st) interface between the SGF and the SVC service 
controller. See clause 4.2. 1 for more detail. 
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Example of st applied to Frame Relay trunking over ATM: 

In a similar fashion to the ATM SVC service interworking example, a logical instantiation of st would be the transport 
of Frame Relay DLCI signalling (which is logically separate from the bearer) from the SGF on a physical port to the 
control function that governs the service on the logical port function of that physical port. .See clause 4.2.6 of [49] for 
more detail. 

Network Service Instance Control Function (NSICF) to Virtual Switch Control Function (VSCF) reference point 

(bs"): 

This reference point provides a means for the NSICF to control the VSF (via the VSCF) for the purpose of making a 
nodal level cross connect. It is used only when a BCF is not used for setting up an end to end bearer. Certain 
implementations of the MSF architecture may include both a bs and a bs' reference point simultaneously. However, 
each reference point would be uniquely responsible for its own separate set of end to end connections. 

Bearer Control Function (BCF) to Virtual Switch Control Function reference point (VSCF) (bs): 

This reference point provides a means for the BCF to control the VSF (via the VSCF) for the purpose of making a nodal 
level cross connect. 

Network Service Instance Control Function (NSICF) to Network Edge Control Function reference point (mb): 

A candidate reference point to be defined in a future MSF release. 

7.3.2.2 Switching - Switching Plane (between same functions ) 

MSF has so far not considered an interface between like-to-like Switching - Switching Planes, since it is assumed that 
communication between Switch Functions interact over the Adaptation Plane. 

7.3.2.3 Adaptation - Adaptation Plane (between same functions) 

The Adaptation- Adaptation Plane interfaces specify the link-by-link bearer protocol stacks used by the various services. 
The intra MSS interfaces standardized by the MSF shall not hinder the full set of bearer capabilities that a Multiservice 
Switching System is expected to support. 



8 Mapping the MSF: MULTI-PLANE system 

architecture onto the TIPHON call control 
architecture 

Figure 8.1 shows the MSF functional architecture as described in clause 7 and in [49]. The MSF architecture is a view 
of the Originating/Terminating Functional group. It does not attempt to expand on the Service Feature Functional Group 
Hence the QoS and Service Profile functions that are shown in the TIPHON release 3 architecture and the UMTS 
architecture for the IMS are not explicitly shown, but are assumed as service specific. 
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- Italicized reference points are not considered open reference points for release 1 . 

- Bearer transport reference points are not shown. 

I Z I - Management functions overlaid on functional architecture 
* The Partitioning Function maintains partition Integrity between partitions of a 
partitioned entity. 



Figure 8.1 : MSF fonctional architecture 

Illustrated below is a cut down section of the TIPHON release 3 functional model, which is an extract of the end-to end 
TIPHON Release 3 functional model described as illustrated in figure 8.1. 
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Figure 8.2: Extract of TIPHON Release 3 Functional Model 

The TIPHON release 3 functional model is then compared to the MSF functional architecture as shown below where 
the functional architectures are aligned for comparison. 
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Figure 8.2a: Comparison of Tiphon Release 3 and IVISF functional Architectures 

Mapping of the control plane functional architectures is then carried out; detailed analysis of the decryptions of the 
functional entities shows a real similarity but the diagram below gives both an indication and a overview. 

The control plane mapping and functional groupings are shown: 

In Red the Service applications and service features. 

In Green the management planes. 

In Blue the Service control functions. 

In Dark Green the call control and switching functions, and 

In brown the Bearer control functions. 
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Transport Plane 



Figure 8.3: Mapping of thie functional groupings between thie lUISF functional Architecture 

and TIPHON release 3 Functional IVIodel 

In conclusion, it is shown that a mapping is possible and that no functions of the MSF functional Architecture are 
omitted. 



Conclusion 



In conclusion, after considering the UMTS IMS architecture in 3GPP Release 5 and 6 and the MSF architecture 
version 1 that the mapping to TIPHON release 3 for Voice over IP functionality is compatible and aligns with the needs 
of the architectures defined by these other bodies. 

In the application plane the functionalities offered by the QoSPE may not be explicitly identified in the MSF 
architecture which sees QoS as service specific. Also the different networks identified in TIPHON are not shown on 
MSF architecture which is an Access Network Architecture. TIPHON shows instances on the Terminal functional 
Group, The Access Network functional Group, The Originating Network Functional Group, Interworking to another 
Network and a Gateway Functional Group. Also, has the resultant functional Groups on the terminating side of the 
session for peer-to-peer communications. 
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Annex A (informative): 

Business roles reference configuration 

The requirement document [7] describes business roles and relationships between them as an example of how business 
relationships in a telecommunications infrastructure can be structm^ed. This annex shows how the different business 
interactions map to the reference points defined in the present document. 



Reference [7] identifies tfie following interactions: 


Corresponding 
Reference point 


1) End User-End User: direct communication between End Users without 3'"'^ party 
intervention. 


not applicable 


2) End User-Retailer: user registration. 


R1 


3) End User-IP Telephony Service provider: call-setup. 


01 


4) End User-Transport Network operator: transport usage accounting, 3'"'^ transport 
flow establishment and 3'"'^ party transport flow reservation. 


T1/I1 


5) Retailer-Retailer: user mobility (e.g. roaming). 


R2/SC2 


6) Retailer-IP Telephony Service Provider: call authorization, user-specific call routing. 


SC2 


7) Retailer-Transport Network Operator: transport resource usage accounting. 


T2/I6 


8) IP Telephony Service provider - IP Telephony Service provider: Inter domain call 
setup. 


C2/C3 


9) IP Telephony Service provider - IP Telephony Service provider (3pty): 3'^'^ party 
call. 


SC2 


1 0) IP Telephony Service provider - Transport Network Operator: transport resource 
usage, 3'"'^ party transport flow establishment and 3'"'^ part transport flow reservation. 


T2 


11) Transport Network Operator - Transport Network Operator (peering): transport 
usage accounting, and transport flow establishment. 


11/12 


12) Transport Network Operator - Transport Network Operator (federation): transport 
resource usage accounting and transport flow establishment. This involves the use of a 
clearinghouse. 


12 
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Figure A.I : Reference points between business roles 
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Annex B (informative): 

non-IP based UIVITS architecture 



In the basic configuration presented in figure 1, all the functions are considered implemented in different equipments. 
Therefore, all the interfaces within PLMN are external. Interfaces A and Abis are defined in the 48-series of Technical 
Specifications. Interfaces lu, lur and lub are defined in the 25.4xx-series of Technical Specifications. Interfaces B, C, D, 
E, F and G need the support of the Mobile Application Part of the signalling system No. 7 to exchange the data 
necessary to provide the mobile service. No protocols for the H-interface and for the I-interface are standardized. All 
the GPRS-specific interfaces (G- series) are defined in the 23-series and 24-series of Technical Specifications. 
Interfaces Mc, Nb, and Nc are defined in TS 123 205 [35] and in the 29-series of Technical Specifications. 



B.1 Basic PLNIVI configuration 



From this configuration, all the possible PLMN organizations can be deduced. In the case when some functions are 
contained in the same equipment, the relevant interfaces become internal to that equipment. 
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Legend: 

Bold lines: interfaces supporting user traffic; 

Dashed lines: interfaces supporting signalling. 

NOTE 1 : The figure shows direct interconnections between the entities. The actual links may be provided by an 

underlying network (e.g. SS7 or IP): this needs further studies. 
NOTE 2: When the MSC and the SGSN are integrated in a single physical entity, this entity is called UMTS MSC 

(UMSC). 
NOTE 3: A (G)MSC server and associated CS-MGW can be implemented as a single node: the (G)MSC. 
NOTE 4: The Gn interface (between two SGSNs) is also part of the reference architecture, but is not shown for 

layout purposes only. 

Figure B.I : Basic Configuration of a PLIVIN supporting CS and PS services and interfaces 
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B.1 a Configuration of CAIVIEL entities 

Figure B.2 shows the interconnection of the CAMEL-specific entities with the rest of the network. Only the interfaces 
specifically involved in CAMEL provisioning are shown, i.e. all the GMSC, MSC, SGSN and HLR interfaces depicted 
in figure 1 are still supported by these entities even if not shown. 

NOTE: The CAMEL-specific interfaces have no particular name. They are designated by the name of the two 
entities they link together, e.g. "the gsmSSF-gsmSCF interface". 




Figure B.2: configuration of CAIVIEL entities 

The bold lines are used for interfaces supporting user data only, the dashed lines are used for interfaces supporting 
signalling only. 



B.2 Functional entities 



B.2.1 General entities 

B.2.1 .1 The Visitor Location Register (VLR) 

A mobile station roaming in an MSC area is controlled by the Visitor Location Register in charge of this area. When a 
Mobile Station (MS) enters a new location area it starts a registration procedure. The MSC in charge of that area notices 
this registration and transfers to the Visitor Location Register the identity of the location area where the MS is situated. 
If this MS is no yet registered, the VLR and the HLR exchange information to allow the proper handling of calls 
involving the MS. 

A VLR may be in charge of one or several MSC areas. 

The VLR contains also the information needed to handle the calls set-up or received by the MSs registered in its data 
base (for some supplementary services the VLR may have to obtain additional information from the HLR). The 
following elements are included: 

the International Mobile Subscriber Identity (IMSI); 

the Mobile Station International ISDN number (MSISDN); 

the Mobile Station Roaming Number (MSRN), see TS 123 003 [17] for allocation principles; 
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the Temporary Mobile Station Identity (TMSI), if applicable; 

the Local Mobile Station Identity (LMSI), if used; 

the location area where the mobile station has been registered; 

the identity of the SGSN where the MS has been registered. Only applicable to PLMNs supporting GPRS and 
which have a Gs interface between MSCA^LR and SGSN; 

the last known location and the initial location of the MS. 

The VLR also contains supplementary service parameters attached to the mobile subscriber and received from the HLR. 
The organization of the subscriber data is outlined in TS 123 008 [19]. 

B.2.1 .2 The Equipment Identity Register (EIR) 

The Equipment Identity Register (EIR) in the GSM system is the logical entity which is responsible for storing in the 
network the International Mobile Equipment Identities (IMEIs), used in the GSM system. 

The equipment is classified as "white listed", "grey listed", "black listed" or it may be unknown as specified in 
TS 122 016 [13] and TS 129 002 [28]. 

This functional entity contains one or several databases which store(s) the IMEIs used in the GSM system. 

The mobile equipment may be classified as "white listed", "grey listed" and "black listed" and therefore may be stored 
in three separate lists. 

An IMEI may also be unknown to the EIR. 

An EIR shall as a minimum contain a "white list" (Equipment classified as "white listed"). 

See also TS 122 016 [13] on IMEI. 

B.2.2 Entities of the CS domain 

B.2.2.1 Tine IVIobile-services Switcining Centre (IVISC) 

The Mobile-services Switching Centre (MSC) constitutes the interface between the radio system and the fixed 
networks. The MSC performs all necessary functions in order to handle the circuit switched services to and from the 
mobile stations. 

In order to obtain radio coverage of a given geographical area, a number of base stations are normally required; i.e. each 
MSC would thus have to interface several base stations. In addition several MSCs may be required to cover a country. 

The Mobile-services Switching Centre is an exchange which performs all the switching and signalling functions for 
mobile stations located in a geographical area designated as the MSC area. The main difference between a MSC and an 
exchange in a fixed network is that the MSC has to take into account the impact of the allocation of radio resources and 
the mobile nature of the subscribers and has to perform in addition, at least the following procedures: 

procedures required for the location registration (see TS 123 012 [21]); 

procedures required for handover (see TS 123 009 [20]). 

NOTE: When this improves the readability (e.g. when dealing with inter-releases handover), the term 2G-MSC 

can be used to refer to an MSC Release 98 or prior, and the term 3G-MSC can be used to refer to an MSC 
Release 99 or later. 

When needed, the MSC can be implemented in two different entities: the MSC Server, handling only signalling, and the 
CS-MGW, handling user's data. A MSC Server and a CS-MGW make up the full functionality of a MSC. 
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B.2.2.1.1 MSC Server 

The MSC Server mainly comprises the call control (CC) and mobility control parts of a MSC. 

The MSC Server is responsible for the control of mobile originated and mobile terminated CC CS Domain calls. It 
terminates the user-network signalling and translates it into the relevant network - network signalling. The MSC Server 
also contains a VLR to hold the mobile subscriber's service data and CAMEL related data. 

The MSC Server controls the parts of the call state that pertain to connection control for media channels in a CS-MGW. 

B.2.2.1 .2 Circuit Switched - Media Gateway Function (CS-MGW) 

NOTE: In the present document the term Media Gateway Function (MGW) is used when there is no need to 

differentiate between the CS domain entity and the IP Multimedia CN Subsystem entity. When referring 
specifically to the CS domain entity the term CS-MGW is used. When referring specifically to the IP 
Multimedia CN Subsystem entity, the term IM-MGW is used. 

This component is PSTN/PLMN transport termination point for a defined network and interfaces UTRAN with the core 
network over lu. 

A CS-MGW may terminate bearer channels from a switched circuit network and media streams from a packet network 
(e.g. RTP streams in an IP network). Over lu, the CS-MGW may support media conversion, bearer control and payload 
processing (e.g. codec, echo canceller, conference bridge) for support of different lu options for CS services 
(AAL2/ATM based as well as RTP/UDP/IP based). 

The CS-MGW: 

• Interacts with MGCF, MSC server and GMSC server for resource control. 

• Owns and handles resources such as echo cancellers etc. 

• May need to have codecs. 

The CS-MGW will be provisioned with the necessary resources for supporting UMTS/GSM transport media. Further 
tailoring (i.e. packages) of the H.248 [42] may be required to support additional codecs and framing protocols, etc. 

The CS-MGW bearer control and payload processing capabilities will also need to support mobile specific functions 
such as SRNS relocation/handover and anchoring. It is expected that current H.248 standard [42] mechanisms can be 
applied to enable this. 

B.2.2.2 The Gateway MSC (GMSC) 

If a network delivering a call to the PLMN cannot interrogate the HLR, the call is routed to an MSC. This MSC will 
interrogate the appropriate HLR and then route the call to the MSC where the mobile station is located. The MSC which 
performs the routing function to the actual location of the MS is called the Gateway MSC (GMSC). 

The acceptance of an interrogation to an HLR is the decision of the operator. 

The choice of which MSCs can act as Gateway MSCs is for the operator to decide (i.e. all MSCs or some designated 
MSCs). 

If the call is a voice group/broadcast call, it is routed directly from the GMSC to the VBS/VGCS Anchor MSC, based 
on information (VBSA'GCS call reference) contained in the dialled number (see also TS 143 068 [33] and 
TS 143 069 [34]). 

When needed, the GMSC can be implemented in two different entities: the GMSC Server, handling only signalling, as 
defined bellow, and the CS-MGW, defined above. A GMSC Server and a CS-MGW make up the full functionality of a 
GMSC. 

B.2.2.2. 1 Gateway MSC Server (GMSC Server) 

The GMSC server mainly comprises the call control and mobility control parts of a GMSC. 
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B. 2.2.3 The Interworking Function (IWF) 



The Interworking Function (IWF) is a functional entity associated with the MSC. The IWF provides the functionality 
necessary to allow interworking between a PLMN and the fixed networks (ISDN, PSTN and PDNs). The functions of 
the IWF depend on the services and the type of fixed network. The IWF is required to convert the protocols used in the 
PLMN to those used in the appropriate fixed network. The IWF may have no functionality where the service 
implementation in the PLMN is directly compatible with that at the fixed network. The interworking functions are 
described in TS 129 007 [29]. 

B.2.3 CAMEL entities 

The entities of this clause support the CAMEL feature (Customized Applications for Mobile network Enhanced Logic). 
This feature provides the mechanisms to support services consistently independently of the serving network, as 
described in TS 122 078 [16]. The following definitions are extracted from TS 123 078 [23], which completely 
specifies CAMEL stage 2. 

B.2.3. 1 GSIVI Service Control Function (gsmSCF) 

A functional entity that contains the CAMEL service logic to implement Operator Specific Service. It interfaces with 
the gsmSSF, the gsmSRF and the HLR. 

B. 2.3.2 GSM Service Switcining Function (gsmSSF) 

A functional entity that interfaces the MSC/GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN 
SSF, but uses different triggering mechanisms because of the nature of the mobile network. 

B.2.3. 3 GSM Specialized Resource Function (gsmSRF) 

A functional entity which provides various specialized resources. It interfaces with the gsmSCF and with the MSC. This 
entity is defined in ITU-T Recommendation Q.1214 [24] with variations defined in TS 123 078 [23]. 

B.2.3.4 GPRS Service Switching Function (gprsSSF) 

A functional entity that interfaces the SGSN to the gsmSCF. The concept of the gprsSSF is derived from the IN SSF, 
but uses different triggering mechanisms because of the nature of the mobile network. 

B.2.4 Number portability specific entities 

Two different solutions are defined to support Number Portability. The first one is an IN based solution and is described 
in the next clause. The second one is a "Signalling Relay" based solution described in next but one clause. 

For details on MNP see TS 123 066 [32]. 

B.2.4. 1 IN-based solution: Number Portability Database (NPDB) 

The Number Portability Database (NPDB) is the central element of the IN based solution for Mobile Number 
Portability (MNP). MNP is the ability for a mobile subscriber to change the GSM subscription network within a 
portability cluster (e.g. a country) whilst retaining his/her original MSISDN or MSISDNs. 

The NPDB stores the table of correspondence between MSISDNs and Subscription networks. Upon request of the 
(gateway or visited) MSC, the NPDB retrieves from the MSISDN the Routing Number pointing out the Subscription 
network. 
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B.2.4.2 Signalling Relay-based solution: Mobile Number 
Portability/Signalling Relay function (MNP-SRF) 

The MNP-Signalling Relay Function (MNP-SRF) is the central element of the Signalling Relay based solution for 
Mobile Number Portability. 

The MNP-SRF obtains the routing information from a NP database to identify the subscription network associated with 
a particular national MSISDN. Upon request from gateway MSC, the MNP-SRF may perform one of the following 
actions: 

1) the MNP-SRF will reply back to the GMSC with the necessary routing information to route the call; 

2) the message is relayed to the HLR; 

3) the message is relayed to MNP-SRF in the subscription network. 

For non-call related signalling (e.g. delivery of SMS), only cases 2 and 3 are applicable. 

B.3 PLMN basic interfaces and reference points 

The implementation of the mobile service with international roaming implies the exchange of data between the 
equipment involved in the service. The same No. 7 signalling network should be used to transfer these data and the 
call-related signalling information. 

B.3.1 Interfaces between Mobile Station and the Fixed 
Infrastructure 

B.3.1 .1 Interface between Mobile Station and Base Station System 
(Um-interface) 

The interface between the MS and the BSS is specified in the 3GPP 44- and 45-series of Technical Specifications. 

B.3.1 .2 Interface between User Equipment and Radio Network System 
(Uu-interface) 

The interface between the UE and the RNS is specified in the 3GPP 24- and 25-series of Technical Specifications. 

B.3. 2 Interface between the Core Network and the Access 
Network 

B.3. 2.1 Interfaces between the CS domain and the Access Network 
B.3. 2.1 .1 Interface between the MSC and Base Station System (A-interface) 

The interface between the MSC and its BSS is specified in the 3GPP 48-series of Technical Specifications. 
The BSS-MSC interface is used to carry information concerning: 

BSS management; 

call handling; 

mobility management. 
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B.3.2.1 .2 Interface between the MSC and Base Station System (lu_CS interface) 

The interface between the MSC and its BSS is specified in the 3GPP 25.41x-series of Technical Specifications. 
The BSS-MSC interface is used to carry information concerning: 

BSS management; 

call handling; 

mobility management; 

B.3.2.1 .3 Interface between the MSC and RNS (lu_CS interface) 

The interface between the MSC and its RNS is specified in the 3GPP 25.41x-series of Technical Specifications. 
The RNS-MSC interface is used to carry information concerning: 

RNS management; 

call handling; 

mobility management. 

B.3.2.2 Interfaces between the PS domain and the Access Network 
B.3.2.2.1 Interface between SGSN and BSS (Gb-interface) 

The BSS-SGSN interface is used to carry information concerning: 

packet data transmission; 

mobility management. 
The Gb interface is defined in TS 148 014 [36], TS 148 016 [37] and TS 148 018 [38]. 

B.3.2.2.2 Interface between SGSN and BSS (lu_PS-interface) 

The BSS-SGSN interface is used to carry information concerning: 

packet data transmission; 

mobility management. 
The Iu_PS interface is defined in the 3GPP 25.41x-series of Technical Specifications. 

B.3.2.2.3 Interface between SGSN and RNS (lu_PS-interface) 

The RNS-SGSN interface is used to carry information concerning: 

packet data transmission; 

mobility management. 
The Iu_PS interface is defined in the 3GPP 25.41x-series of Technical Specifications. 
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B.3.3 Interfaces internal to the Core Network 

B.3.3.1 Interfaces internal to the CS domain 

B.3.3. 1 .1 Interface between the MSC server and its associated VLR (B-interface) 

The VLR is the location and management database for the mobile subscribers roaming in the area controlled by the 
associated MSC server(s). Whenever the MSC server needs data related to a given mobile station currently located in its 
area, it interrogates the VLR. When a mobile station initiates a location updating procedure with an MSC server, the 
MSC server informs its VLR which stores the relevant information. This procedure occurs whenever an MS roams to 
another location area. Also, when a subscriber activates a specific supplementary service or modifies some data 
attached to a service, the MSC server informs (via the VLR) the HLR which stores these modifications and updates the 
VLR if required. 

This interface is internal to the MSC server /VLR; signalling on it is not standardized. 

B.3.3.1 .2 Interface between the HLR and the MSC server (C-interface) 

The Gateway MSC server must interrogate the HLR of the required subscriber to obtain routing information for a call or 
a short message directed to that subscriber. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (see TS 129 002 [28]). 

For CAMEL purposes, this interface is used as described in TS 123 078 [23]. It is used e.g. at terminating calls to 
exchange routeing information, subscriber status, location information, subscription information, etc. 

B.3.3.1 .3 Interface between the HLR and the VLR (D-interface) 

This interface is used to exchange the data related to the location of the mobile station and to the management of the 
subscriber. The main service provided to the mobile subscriber is the capability to set up or to receive calls within the 
whole service area. To support this, the location registers have to exchange data. The VLR informs the HLR of the 
location of a mobile station managed by the latter and provides it (either at location updating or at call set-up) with the 
roaming number of that station. The HLR sends to the VLR all the data needed to support the service to the mobile 
subscriber. The HLR then instructs the previous VLR to cancel the location registration of this subscriber. Exchanges of 
data may occur when the mobile subscriber requires a particular service, when he wants to change some data attached to 
his subscription or when some parameters of the subscription are modified by administrative means. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (see TS 129 002 [28]). 

For CAMEL purposes, this interface is used to send the CAMEL related subscriber data to the visited PLMN and for 
provision of MSRN. The interface is also used for the other purposes described in TS 123 078 [23], e.g. to retrieve 
subscriber status and location information of the mobile subscriber or to indicate suppression of announcement for a 
CAMEL service. 

B.3.3.1 .4 Interface between MSC servers (E-interface) 

When a mobile station moves from one MSC area to another during a call, a handover procedure has to be performed in 
order to continue the communication. For that purpose the MSC servers have to exchange data to initiate and then to 
realize the operation. 

After the handover operation has been completed, the MSC servers will exchange information to transfer A-interface 
signalling as necessary. 

When a short message is to be transferred between a Mobile Station and Short Message Service Centre (SC), in either 
direction, this interface is used to transfer the message between the MSC server serving the Mobile Station and the 
MSC server which acts as the interface to the SC. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (see TS 129 002 [28]). 
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B.3.3.1 .5 Interface between MSC server and EIR (F-interface) 

This interface is used between MSC server and EIR to exchange data, in order that the EIR can verify the status of the 
IMEI retrieved from the Mobile Station. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (see TS 129 002 [28]). 

B.3.3.1 .6 Interface between VLRs (G-interface) 

When a mobile subscriber moves from a VLR area to another Location Registration procedure will happen. This 
procedure may include the retrieval of the IMSI and authentication parameters from the old VLR. 

Signalling on this interface uses the Mobile Application Part (MAP), which in turn uses the services of Transaction 
Capabilities (see TS 129 002 [28]). 

B.3.3.1 .7 Reference point (G)MSC server - CS-MGW (Mc Reference Point) 

The Mc reference point describes the interfaces between the MGCF and IM-MGW, between the MSC Server and 
CS-MGW, and between the GMSC Server and CS-MGW. It has the following properties: 

• full compliance with the H.248 standard [42], baseline work of which is currently carried out in ITU-T Study 
Group 16, in conjunction with IETF MEGACO WG; 

• flexible connection handling which allows support of different call models and different media processing 
purposes not restricted to H.323 usage [43]; 

• open architecture where extensions/Packages definition work on the interface may be carried out; 

• dynamic sharing of MGW physical node resources. A physical MGW can be partitioned into logically separate 
virtual MGWs/domains consisting of a set of statically allocated Terminations; 

• dynamic sharing of transmission resources between the domains as the MGW controls bearers and manage 
resources according to the H.248 protocols [42]. 

The functionality across the Mc reference point will need to support mobile specific functions such as SRNS 
relocation/handover and anchoring. It is expected that current H.248/IETF Megaco standard [42] mechanisms can be 
applied to enable this. 

B.3.3.1 .8 Reference Point MSC Server - GMSC Server (Nc Reference Point) 

Over the Nc reference point, the Network-Network based call control is performed. Examples of this are ISUP or an 
evolvement of ISUP for bearer independent call control (BICC). Different options for signalling transport on Nc shall 
be possible including IP. 

B.3.3.1 .9 Reference Point CS-MGW - CS-MGW (Nb Reference Point) 

Over the Nb reference point the bearer control and transport are performed. The transport may be RTP/UDP/IP [46], 
[47] or AAL2 [44] for transport of user data. Different options for user data transport and bearer control shall be 
possible on Nb, for example: AAL2/Q.AAL2, STM/none, RTP/H.245 [45]. 

B.3.3.2 Interfaces used by CS-domain 

B.3.3.2.1 Interface between MSC/VLR and SGSN (Gs-interface) 

The SGSN may send location information to the MSC/VLR via the optional Gs interface. The SGSN may receive 
paging requests from the MSC/VLR via the Gs interface. The MSC/VLR may indicate to an SGSN, via the Gs 
interface, that an MS is engaged in a service handled by the MSC. 

Signalling on this interface uses connectionless SCCP (without TCAP). SCCP Global Title (GT) is used for addressing. 
The Gs-interface is defined in TS 129 016 [39] and TS 129 018 [40]. 
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B.3.3.2.2 Interface between HLR and AuC (H-lnterface) 

When an HLR receives a request for authentication and ciphering data for a Mobile Subscriber and it does not hold the 
requested data, the HLR requests the data from the AuC. The protocol used to transfer the data over this interface is not 
standardized. 

B. 3.3.3 CAMEL-specific interfaces 

The CAMEL-specific interfaces are detailed in TS 123 078 [23]. These interfaces are. 

B.3.3.3.1 GMSC - gsmSSF interface 

This is an internal interface. The interface is described in the specification to make it easier to understand the handling 
of Detection Points (arming/disarming of DPs, DP processing etc.). 

B.3.3.3.2 gsmSSF - gsmSCF interface 

This interface is used by the gsmSCF to control a call in a certain gsmSSF and to request the gsmSSF to establish a 
connection with a gsmSRF. Relationships on this interface are opened as a result of the gsmSSF sending a request for 
instructions to the gsmSCF. 

B.3.3.3.3 MSC - gsmSSF interface 

This is an internal interface. The interface is described in the specification to make it easier to understand the handling 
of DPs (arming/disarming of DPs, DP processing etc.). 

B.3.3.3.4 gsmSCF - HLR interface 

This interface is used by the gsmSCF to request information from the HLR. As a network operator option the HLR may 
refuse to provide the information requested by the gsmSCF. 

This interface is also used for USSD operations, both for gsmSCF-initiated dialogues and MS-initiated dialogues 
(relayed via HLR). It is a network operator option whether to support or not USSD operations on this interface. 

B.3.3.3.5 gsmSCF - gsmSRF interface 

This interface is used by the gsmSCF to instruct the gsmSRF to play tones/announcements to the users. 

B.3.3.3.6 MSC - gsmSCF interface 

This interface is used by the MSC to send supplementary service invocation notifications to the gsmSCF. 

B.3.3.3.7 SGSN - gprsSSF interface 

This is an internal interface. The interface is described in the specification to make it easier to understand the handling 
of DPs (arming/disarming of DPs, DP processing etc.). 

B.3.3.3.8 gprsSSF - gsmSCF interface 

This interface is used by the gsmSCF to control a GPRS session or individual PDP Context in a certain gprsSSF. 
Relationships between the gprsSSF and the gsmSCF (GPRS dialogues) on this interface are opened as a result of the 
gprsSSF sending a request for instructions to the gsmSCF. 
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B.3.3.4 Number portability specific interfaces 
B.3.3.4.1 IN-based solution 
B.3.3.4.1 .1 NPDB to MSC interface 

Upon receiving an ISUP lAM, the (gateway or visited) MSC send a database query to the NPDB as a result of analysis 
of the received MSISDN. The MSISDN is included in the query to the NPDB. The NPDB determines whether the 
MSISDN is ported or not. If not, it responds back to the MSC to continue the normal call setup procedure for MT calls 
(optionally providing the Routing Number). If it is ported, the NPDB responds back to the MSC with a Routing Number 
pointing out the Subscription network. 

B.3. 3.4.2 Signalling Relay-based solution 
B.3.3.4.2.1 GMSC to MNP-SRF interface 

Upon receiving an ISUP lAM, the gateway MSC sends a routing interrogation to the MNP-SRF, which in turn will 
perform one of the actions, depending on the portability status of the subscriber and the network configuration 

(see TS 123 066 [32]). 

B.3.3.4.2.2 MNP-SRF to HLR interface 

When the MNP-SRF receives a routing interrogation from the GMSC or an interrogating network entity (non/call 
related signalling), and it determines that the subscriber is not ported or it has been ported from another network, the 
MNP-SRF relays the message to the HLR. 
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Annex C (informative): 

TIPHON Release 3 functional architecture 

The architecture for the IP based telephony application plane implements the capabilities necessary for the IP based 
telephony application. This architecture is defined in [6]. The following text is an extract of the published TIPHON 
release 3 material, issue xyz. In the Mapping defined in the present document the generalized application plane may 
divide the IP based Telephony application plane into the IP control plane and the Application plane. 

The IP based telephony application architecture is described using objects. These objects are related to each other but 
may be instantiated and deleted separately. 

One or more objects, taken together, exhibit the behaviour of the functional entities described in the present document. 
The functionality in the IP telephony application plane is distributed within functional layers based on object lifetime 
and object ownership. Each functional layer provides capabilities to adjacent layers. This grouping is useful to 
understand the functionality involved but does not imply any physical implementation. 

Where there is a requirement for an interface between functional entities a reference point is defined. 



C.1 Introduction to the functional layers 

The IP Telephony Application plane has 5 functional layers: the Services functional layer, the Service Control 
functional layer, the Call Control functional layer, the Bearer Control functional layer and the media functional layer. 

These functional layers are shown in figure C.4. For simplicity only two functions are shown in each functional layer 
with all of the possible communication paths within the functional layer and to the adjacent functional layers. 
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Figure C.I : Functional layers in the IP Telephony Application plane 

Each of the functional layers is introduced in the subsequent clauses. 



ETSI 



69 



ETSI TS 102 261 VI. 1.1 (2003-09) 



C.1 .1 The services functional layer 



The Services functional layer contains the collections of data and associated logic (e.g. scripts) that produce service 
functions. The services functional layer is related to the service and registration capabilities identified in [1]. A service 
capability may use more than one function in the Services functional layer and functions in other layers. 

NOTE 1 : The collections of data and logic (service functions) may be held in many different places and may be 

owned and run by service providers who create services over networks run by other parties. These service 
functions may interact with each other way to control registration and to control calls. 

Call related service functions are accessed by the Call Control functional layer through the services control functional 
layer. Registration related functions, are accessed by the Service Control functional layer. 

NOTE 2: The following illustrates the operation of the Call Control functional layer, the Service Control functional 
layer and the Services functional layer. When a caller requests a call, the call control layer interrogates the 
Services functional layer (via the Service Control functional layer) for the caller's profile and any other 
service functions needed. Using this information, the Call Control functional layer sends a request for a 
call towards the called party. This request may be modified by an intermediate network (e.g. re-routed) 
but eventually arrives at the Call Control functional layer of the called party. This Call Control functional 
layer interrogates the called user's profile and other relevant service functions and determines whether or 
not the call can be accepted and if not what reply should be sent. 

This functional layer has the following functions: 



User-service profile function 


This function is present in a terminal registration functional group. It provides 

information required for registration and stores information received during 

registration (user related information pertaining to the services the user wants 

to register for as well as information on the service provider with whom the 

service shall be registered). 

It provides, on request, information needed for call establishment (such as 

authorization information and user preferences). 

The lifetime of this information is valid as long as the user has the contract with 

the service provider this service profile refers to. 



User profile function 


This function is present in the home network functional group. It holds 
information about the user. 

The lifetime of this information is valid as long as the user has the contract with 
the service provider this service profile refers to. 



Call Routing (CR) function 


This function is present in any network functional group. It provides 

address/number translation, number length determination and telephony 

routing capabilities. 

This function will exist as long as the service provider exists. The lifetime of the 

Information contained in this function is as long as the call routing information is 

valid. 



Accounting function 


This function is present in any network functional group. It handles and stores 

call and service related information. The stored information may be used for 

billing the user or other operators. 

This function will exist as long as the service provider exists. The lifetime of 

information in this function is at least as long as the legal time to keep such 

information. 



QoS Policy (QoSP) function 


This function is present in any network functional group. It manages IP 
Telephony QoS policies and provides authorization of permitted and default 
QoS levels. 

This function will exist as long as the service provider exists. The lifetime of 
information in this function is as long as the QoS policies stay the same. 
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C.1 .2 The Service Control functional layer 

The Service Control functional layer provides two classes of functions: 

management of registrations; and 

support for calls. 

To manage registrations, this layer: 

receives information from the terminal about the user and generates requests for authentication from its own 
services functional layer or a remote services functional layer via a peer Service Control functional layer; and 

processes the responses from the Services functional layer and generates authorization "tickets" that are stored 
in the user's terminal. These tickets are then used with call requests. 

To support calls, this layer: 

receives requests from the call control functional layer and generates requests for information to the 
appropriate services functions, which may be local or remote and may also be provided by third parties; and 

processes the responses from the service functions to produce and return responses to call control. 

The Service Control functional layer is related to service capabilities and registration capabilities identified in [1]. A 
service capability may use more than one function in the Service Control functional layer and functions at other layers. 

This functional layer has the following functions: 



Service Control (SC) function 


This function is present in any networl< functional group. It provides 
support for calls by accessing information at the services layer This 
support mainly concerns authorization and routing, including name and 
address translations. 

This function exists as long as the service provider provides this type of 
service application. 



Terminal Registration (TREG) function 



This function is present in terminal registration functional group. It 
registers a user at a terminal with a service provider. This function lives 
as long as the user has a registration session with the network. 



Service Network Registration (SREG) 
function 



This function is present in the serving network functional group. It 
accepts registration of a user at a terminal. 

This function exists as long as the user has a registration session with 
the network. 



Intermediate Network Registration (IREG) 
function 



This function is present in the intermediate network functional group. It 
accepts registration requests from user at a terminal via the serving 
network functional group and proxies the request towards the home 
network functional group. 

This function exists as long as the user has a registration session with 
the network. 



Home Network Registration (HREG) function 



This function is present in the home network functional group. It accepts 
registration of a user at a terminal. 

This function exists as long as the user has a registration session with 
the network. 
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C.1 .3 The Call Control functional layer 



The Call Control functional layer shall maintain a call context. The call context allows the Bearer Control functional 
layer to provide the connections and capabilities requested by the user (as permitted by the service provider). In order to 
achieve this control, the Call Control functional layer may request information from the Service Control functional 
layer. 

The Call Control functional layer is related to the service and registration capabilities identified in [1]. A service 
capability may use more than one function in the Call Control functional layer and functions at other layers. 

This functional layer has the following functions: 



Call Control (CC) function 


This function is present in any networl< functional group. It maintains the 

call state and, if present, provides services that change the call state 

e.g. call forwarding, call transfer and conferencing. This function has the 

same lifetime as the call it controls. 

Communication with peer Call Control functions for the establishment and 

release of calls. 

Requests services from functions in the Service Control functional layer. 

Request determination of, allocation of, and release of, resources from 

Bearer Control functions. 



C.1 .4 The Bearer Control functional layer 

The Bearer Control functional layer manages the logical association between pairs of endpoints. Bearer Control shall 
be responsible for mapping call topology to individual media flows (e.g. connect parties a, b and c together). These 
flows may be between any pair of media processing functions in the media functional layer. 

The Bearer Control functional layer is related to the service and registration capabilities identified in [1]. A service 
capability may use more than one function in the Bearer Control functional layer and functions at other layers. 

This layer has the following functional functions: 



Bearer Control (BC) function 

• Bearer negotiation 

• IVIedia resource acquisition 


This function is present in any network functional group. It allows or 
disallows media streaming based on information from call control. This 
function has the same lifetime as the bearer that it controls. 
Negotiates with other Bearer Control functions. 

Communicates with the IVIedia Control function to obtain media resources 
for the bearer. 



Aggregate Bearer Admission Control 
(ABAC) function 



This function is present in any network functional group. It determines 

whether or not a flow is to be admitted as part of an established 

Aggregate Bearer. It also keeps track of the capacity available for flows 

as they may change for reasons other than the admission or cessation of 

media flows. 

Interfaces to the management plane for the retrieval of Aggregate Bearer 

parameters. 

This function has the same lifetime as the aggregate bearer that it 

controls. 



NOTE: The Quality of Service Manager (QoSM) functional element defined in reference [2] includes all those 
aspects of the Media and Bearer Control layers, within a particular functional group, that are involved in 
end to end QoS specification and control. 
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C.1 .5 The Media Control functional layer 

The Media Control functional layer shall be responsible for the properties of the individual media flows. In this 
functional layer media encoding capability is determined, Quality of Service (QoS) paths are reserved and firewalls are 
controlled in conjunction with the IP based Transport plane. 

The Media Control functional layer is related to the service and registration capabilities identified in [1]. A service 
capability may use more than one function in the Media Control functional layer and functions at other layers. 

This functional layer has the following functions. 



Media Control (MC) functions 

• Circuit Networl< IVIedia Termination 

• IVIedia Processing 

• IVIedia Resource Management 

• Packet Media Termination 

• Transport signalling 


Provides IP transport addresses for media reception and transmission. 

This function has the same lifetime as the media it controls. 

This function is present in the Gateway functional group. It provides 

termination of for example: all lower-functional layer circuit network 

hardware and protocols. 

This function may be present in any functional group. It performs signal 

processing functions such as voice compression, network 

echo-cancellation, silence suppression, comfort noise generation, 

encryption, codec translation, fax conversion, media insertion (DTMF, 

messages) filtering and analogue modem conversion (for passing 

analogue modem signals "transparently" through the packet network). 

This function is present in any functional group. It allocates internal 

resources in the media plane 

This function is present in any functional group. It performs termination 

of application data transport protocol 

This function is present in any functional group. It reserves QoS paths 

and controls firewalls in the IP based Transport plane. 



Aggregate Bearer Measurement (ABM) 
function 



This function is present in any network functional group. 

It determines the capacity used and remaining in an Aggregate Bearer 

as a result of measuring the actual media flows after taking into 

account what flows were requested. 

Its interfaces with the management plane for the retrieval of Aggregate 

Bearer parameters 

This function has the same lifetime as the Aggregate Bearer that it 

measures. 



NOTE: The Quality of Service Manager (QoSM) functional element defined in [2] includes all those aspects of 
the Media and Bearer Control layers, within a particular functional group, that are involved in end to end 
QoS specification and control. 



C.2 Definition of reference points 

Reference points are identified for those (groups of) information flows that are to be subject of standardization. This 
clause describes the reference points, defined in the IP based telephony application plane (and the relation to other 
planes) and shows how they can be combined to provide the application over IP networks. 

The internal structure of the management plane is defined in [4] and the internal structure of the IP based transport 
plane is defined in clause 6 in the present document. 

Figure C.2 shows the reference points in the general functional model. 
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NOTE 1 : All functions within the network functional group may appear more than once. In the figure the Registration 
function and the SC function appears more than once to show inter domain reference points R2 and SC2'. 
For simplicity the reference points from SC to the Service layer is not repeated but should be the same as 
for any other SC in the network functional group i.e. S2, S3, S4 and A35. 

NOTE 2: The reference point A55 corresponds to the reference point A in [4] and reference point S5 in the present 

document. 
NOTE 3: Parts of the Aggregated Bearer Admission Control (ABAC) and the Aggregated Bearer IVIanagement 
(ABM) function belongs to the Management Plane. Aggregate Bearer load control information flows 
between ABM and ABAC at N2 with the capability to provide admission control functionality based on 
aggregate bandwidth usage measurements and transport network QoS performance. 

Figure C.2: General reference configuration 

Call Control functions shall be present in all networks involved in handling a call. Instances of lower layer functions 
may be created or destroyed as needed for a particular call. Bearer Control functions shall not be created for networks 
that choose not to directly control functions in the IP based transport plane. A Bearer Control function shall be created 
when bearer re-negotiation is required, however the media control function and transport functions may not be needed. 

Figure C.2 shows the general reference configuration. In order to understand how the functions, within that general 
model, interact for different scenarios each scenario is described in separate figures. 

Clause 5.2.1 provides the call unrelated reference point configurations and clause 5.2.9 provides the call related 
reference point configurations. 



C.2.1 

SI: 

S2: 

S3: 



SC-Service reference points 



Information flows at S 1 provide the capability to store, retrieve and delete the registration ticket. 

Information flows at S2 provide the capability to get and set properties in the user profile. For the 
purposes of: User authentication, user authorization, call routing, user preferences, allowed services and 
service options. 

Information flows at S3 provide the capability to get call routing information and address translation. 
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S4: Information flows at S4 provide the capability to get QoS information. 

S5: Information flows at S5 provide the capability to store and receive accounting information from the 

management plane. 



C.2.2 SC-SC reference points 



Rl: Information flows at Rl provide the capability required for a user to register with the serving IPTN. They 

provide the capability to convey users ID, terminal ID, terminal capabilities etc. 

R2: Information flows at R2 provide the capability so that networks can exchange user registration and 

information related to user profile and subscription. 

SC2': Information flows at SC2' provide the capability to answer service related queries, e.g. to answer access 
and routing requests for calls in the context of Network Functional Groups. Input information may 
include called address/name, caller, calling domain. Output information may include next-hop address, 
preferences and constraints for the call parameters. 

C.2.3 CC-SC reference points 

SCI: Information flows at SCI provide the capability to get a ticket on an existing registration session. 

SC2: Information flows at SC2 provide the capability to answer service related queries, e.g. to answer access 

and routing requests for calls in the context of Network Functional Groups. Input information may 
include called address/name, caller, calling domain. Output information may include next-hop address, 
preferences and constraints for the call parameters. 



C.2.4 CC/BC-CC/BC reference points 



Cl: Information flows at CI provide the capability to establish, modify and terminate both calls and bearers to 

and from the terminal. 

C2: Information flows at C2 provide the capability to establish, modify and terminate both calls and bearers 

between non-terminal functional groups. 

C3: Information flows at C3 provide the capability to establish, modify and terminate calls and connections 

between non-terminal functional groups using an SCN. 



C.2.5 IVIC-BC reference points 



Nl: Information flows at Nl provide the capability to request, modify and delete media paths for the creation 

of a bearer in the context of terminal functional group. 

N2: Information flows at N2 provide the capability to request, modify and delete media paths for the creation 

of a bearer and provide the capability to control an insertion of information (e.g. tones and 
announcements) into media flows in the context of network functional group. Information flows at the N2 
provide Aggregate Bearer load admission control based on aggregate bandwidth usage measurements. 

N3: Information flows at N3 provide the capability to request, modify and delete media paths for the creation 

of a bearer in the context of gateway functional group. Information flows at the N3 provide Aggregate 
Bearer load admission control based on aggregate bandwidth usage measurements. 



C.2.6 IVIC-IVIC reference points 



Ml 

M2 
M3 



Information flows at Ml provide the capability to carry media flows between the terminal and the IPN. 
Information flows at M2 provide the capability to carry media flows over the IPN. 
Information flows at M3 provide the capability to carry media flows over the SCN. 
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C.2.7 

Tl: 
T2: 
T3: 



TR-MC reference points 



Information flows at Tl provide the capability to permit, modify and inhibit transport capabiUties for the 
terminal, including Quality of Service, for the creation of a media flow. 

Information flows at T2 provide the capability to permit, modify and inhibit transport capabilities for the 
IPTN, including Quality of Service, for the creation of a media flow. 

Information flows at T3 provide the capability to permit, modify and inhibit transport capabilities for the 
SCN, including Quality of Service, for the creation of a media flow. 



C.3 Introduction to the functional layers 

The IP based Transport plane has 3 functional layers: the transport service functional layer, the transport control 
functional layer and the transport flow functional layer. 

These functional layers are shown in figuer C.3. For simplicity only two functions are shown in each functional layer 
with all of the possible communication paths within the functional layer and to the adjacent functional layers. 



Transport 
Service 



Transport 
Control 



Transport 
Flow 



Figure C.3: Functional layers in the IP transport plane 

In the subsequent clauses each of the functional layers is introduced. 



C.3.1 Transport service functional layer 

The transport service functional layer shall contain functionality that is needed for the transport service as defined in 
TR 101 311 [5] and TR 101 877 [8], and has a life span longer or shorter than the duration of a transport session. 



Transport Policy (TP) function 



Maintains the policies of the transport domain in which it is situated. 
This function will exist as long as the service provider exists. The 
lifetime of information in this function is as long as the transport 
policies stay the same. 



Transport Accounting (TA) 
function 



Records transport usage information that may be used for accounting 
purposes, within the transport domain where it is situated. This 
function will exist as long as the service provider exists. The lifetime 
of information in this function is at least as long as the legal time to 
keep such information. 



C.3.2 Transport control layer 



The transport control functional layer shall contain functionality that is needed for the transport session. 
It provides an interface to the IP based Telephony Application plane and other transport domains. 
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Transport Resource Manager 
(TRM) function 



Applies a set of policies and mechanisms to a set of transport 
resources to ensure that those resources are allocated such that they 
are sufficient to enable QoS guarantees across the domain of control 
of the TRM. This function has a lifetime as long as long as the 
transport flow. communicates with ICF to enforce the policy. 
Communicates with other TRMs to establish the QoS profile on a 
stream (e.g. RSVP). 



C.3.3 Transport flow layer 



The transport flow functional layer provides the capability to transport and police (packet) flows. 



Inter Connect Function (ICF) 



Interconnects transport domains with entities outside of the transport 

domain. 

Enforces packet flow policy as specified by the TRIVI. 

Tags packet flows with QoS information (e.g. DiffServ/MPLS). 

Provides usage measurements for e.g. Aggregate Bearer load 

thresholds. 



Transport Function (TF) 



Transport resources within a Transport Domain capable of QoS 
control. 



C.4 Definition of transport reference point 

Reference points are identified for those (groups of) information flows that are to be subject of standardization. The rest 
of this clause describes the reference point, defined in the IP based transport plane, and shows how they can be 
combined to support the IP telephony application plane with means of controlling media flows. The definition of the IP 
based Transport for the User Transport domains and the Ingress/Egress transport domains can be found in [9], [10], [6], 
[12], [14] and [15]. 

Figure C.4 shows reference points within the IP transport plane and the relation to the IP based telephony application 
plane. 
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Figure C.4: Reference points in the Transport plane 
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C.4.1 Transport control - transport service reference points 

14: The reference point is between a TRM and its associated TP. 

16: The reference point is between the TRM and the TA. The information flow across the reference point 

transports usage related information that enables accounting of used resources within the IP Transport 
plane. 

C.4.2 Transport control - transport control reference points 

II: The reference point is between a TRM and a User Equipment TRM. The QoS information flow across 

this reference point communicates the required QoS characteristics of the related local loop transport 
flows that will carry the media flow, the properties of the media flow, and possibly addressing 
information related to the transport flows. 

12: The reference point is between two TRMs in different network transport domains. The information flow 

across this reference point communicates the required QoS characteristics of the related interconnect 
transport flows that will carry the media flow, the properties of the media flow, and possibly addressing 
information related to the transport flows. 

C.4.3 Transport flow - transport control reference points 

13: The reference point is between a TRM and an ICF. The information flow across this reference point 

controls the ICF and enables it to perform its interworking and policing functions. 

15: This reference point is between TRM and TF. The information flow across this reference point ensures 

the creation and deletion of transport flows across the TF possibly with QoS. 
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